Geckozone

Tu veux dire franciser mon nvu(en par default). Ou installer une nouvelle version fr en root ?

Pack de langue XPI
Le pack de langue XPI est réservé aux personnes qui savent ce qu'elles font !
Il n'existe pas dans l'interface de Nvu de menu pour sélectionner la langue, ce choix devant être fait par des options de la ligne de commande.
Après l'installation du pack, il est donc nécessaire de modifier la ligne de commande (ou le raccourci) de lancement de Nvu et d'y ajouter :
-contentLocale FR -UILocale fr-FR

Si vous avez opté pour la version .zip/.tar.bz2
Lorsque vous avez téléchargé le fichier, bunzip2 sous Linux pour décompresser Nvu dans un répertoire vide, ensuite lancez nvu.

Je me tate. Je suis adepte des rpm

Sous linux si tu le caches il se prend un . devant (ou inversement si tu mets un . devant il se cache). Du coup avec apache le fichier n'est plus visible sur le net puisque la config par defaut d'apache interdit l'acces a ce genre de fichier. Sous xp ca doit etre identique ?

Do-IT a écrit :Tu veux dire franciser mon nvu(en par default). Ou installer une nouvelle version fr en root ?

Tu peux aussi installer le pack de langue FR (xpi). Si tu installes locales-switcher, le choix de la langue devient persistant, et mes extensions deviennent réellement multilingues (encore une extension qui devrait être intégrée à Nvu).

Do-IT a écrit :Sous linux si tu le caches il se prend un . devant (ou inversement si tu mets un . devant il se cache). Du coup avec apache le fichier n'est plus visible sur le net puisque la config par defaut d'apache interdit l'acces a ce genre de fichier. Sous xp ca doit etre identique ?

Bonne remarque, ça mérite une nouvelle beta.
Sous XP je ne sais pas si ça va masquer le fichier coté Apache, mais je m'en f*** un peu, de toutes façons un serveur web ne peut pas tourner de façon fiable sous Windaube, donc la question de sécurité ne se pose pas.

Kaze a écrit :Tu peux aussi installer le pack de langue FR (xpi). Si tu installes locales-switcher, le choix de la langue devient persistant, et mes extensions deviennent réellement multilingues.

Impeccable !!!
Message d'erreur disparu.
Un vrai bonheur de voir du code source humainement lisible dans l'onglet source sous linux ! A se demander si l'influance des loups lunatiques y est pour quelque chose. Sous Mac c'est comment ? Merdique comme sous windaube ?

L'editeur externe veut pas demarrer. j'ai essayé avec kwrite puis /usr/bin/kwrite
(tidy non installé)

Code : Tout sélectionner

Erreur : FilePath is not defined
Fichier source : chrome://handcoder/content/kazio.js
Ligne : 121

OK. Quand je mets Tidy sur demande uniquement, fatalement ca fonctionne mieux ! Kwrite s'ouvre (Pas mal cette editeur : coloration, indentation ?, fermeture de balises, ... Adieu scite de toute facon je t'aimais pas !)

Do-IT a écrit :Un vrai bonheur de voir du code source humainement lisible dans l'onglet source sous linux !

L'oeil de gu...

L'onglet "Source" devient subitement intéressant pour éditer un fragment 100% PHP, je viens de comprendre ça. Je ne m'en étais jamais rendu compte, je suis trop accro à SciTE.
Il ne manquerait plus qu'un petit bricolage pour virer le <br> de trop et garder les onglets... et utiliser CR/LF plutôt que LF en caractère de fin de ligne, évidemment.

Do-IT a écrit :L'editeur externe veut pas demarrer. [...] Quand je mets Tidy sur demande uniquement, fatalement ca fonctionne mieux !

Il faudrait surtout que je prenne en compte le cas où Tidy n'est pas installé (y'a des gens qui utilisent Nvu sans Tidy ???). A corriger.

Do-IT a écrit :Kwrite s'ouvre (Pas mal cette editeur : coloration, indentation ?, fermeture de balises, ... Adieu scite de toute facon je t'aimais pas !)

Kwrite est très bien, léger et performant, comme SciTE !

Je l'utilise principalement chez mes potes (je suis fidèle à mon bureau 100% GTK), donc je le connais beaucoup moins bien.
Il est basé sur Qt et serait donc, théoriquement, portable sous Mac et Windaube ; malheureusement je n'ai pas trouvé de portages valables sur ces plate-formes. Il est dockable dans Nvu lui aussi, mais sa licence est différente de celle de Scintilla (j'ai pas encore compris toutes les subtilités).

<p id="VimIsBetterThanEmacs"> Après il y a Vim : je crois que plus on l'utilise, plus on devient accro. Malheureusement son efficacité se paye par une ergonomie trop technique, et sa licence ne me convient pas. Il est complètement multiplate-formes, c'est l'éditeur externe parfait. </p>

C'est clairement entre Kwrite et SciTE que la question se poserait pour docker un éditeur texte dans Nvu. Les deux seraient à la fois beaucoup plus réactifs, plus fiables et plus complets que l'onglet "Source". Et contrairement à lui, ils peuvent contenir plusieurs documents.
A contrario, je dois reconnaître que l'onglet "Source" m'a fait de bonnes surprises ces jours-ci. Le docker dans Nvu ne serait peut-être pas si crétin... Bref, à méditer pour la suite.

Un crétin a écrit :
Do-IT a écrit :Un vrai bonheur de voir du code source humainement lisible dans l'onglet source sous linux !
L'oeil de gu...
L'onglet "Source" devient subitement intéressant pour éditer un fragment 100% PHP, je viens de comprendre ça. Je ne m'en étais jamais rendu compte, je suis trop accro à SciTE.
Il ne manquerait plus qu'un petit bricolage pour virer le <br> de trop et garder les onglets... et utiliser CR/LF plutôt que LF en caractère de fin de ligne, évidemment.

Il ne s'agit pas d'un problème de CR/LF. L'indentation est bien présentée à l'ouverture, mais si on fait une modif en mode "Source", Nvu détruit l'indentation des scripts PHP quand on revient à l'onglet "Normal", sous Linux comme sous Windaube.

M'est avis qu'un éditeur texte est plus adapté pour ouvrir des fragments 100% PHP, au moins pour l'instant. Le problème des scripts de plus d'une ligne ne sera réellement résolu qu'en intégrant aStyle et/ou en remplaçant l'onglet "Source" par un vrai éditeur de texte.

Do-IT a écrit :Essaie d'ouverture de ce fragment php => Il se passe rien
Code : Tout sélectionner
<?php if ($condition) { die('</body></html>'); } ?>
La meme chose dans un document html complet fonctionne.

Ce type de fragment ne peut pas être ouvert par Nvu (cf. mon billet page précédente) ; si tu veux absolument garder cette façon de procéder, tu peux utiliser ça :

Code : Tout sélectionner

<?php if ($condition) { die('</body'+'></'+'html>'); } ?>

Pas glorieux mais ça peut dépanner...

Kaze a écrit :si on fait une modif en mode "Source", Nvu détruit l'indentation des scripts PHP quand on revient à l'onglet "Normal", sous Linux comme sous Windaube. ... un éditeur texte est plus adapté pour ouvrir des fragments 100% PHP, au moins pour l'instant. Le problème des scripts de plus d'une ligne ne sera réellement résolu qu'en intégrant aStyle et/ou en remplaçant l'onglet "Source" par un vrai éditeur de texte.

Effectivement l'indentation des scripts php intégrés a une page html est detruite. Tout le php se retrouve sur une seule ligne. Ca n'a pas l'air de géner le serveur mais il n'y a plus de lisibilité. L'editeur texte externe à encore de beau jour devant lui en attendant kzspro. C'est autant inéditable dans l'onglet source que ca le sera probablement dans le source docké. (Bientôt Pâques). D'où bis repetitas ma phrase favorite : suppression de l'onglet source.
Je voie bien une extenstion qui supprime ca et les boutons maudits et peut-etre d'autres choses. 8)
Finalement ca fait plaisir d'avoir à nouveau une version de handcoder qui support le php

Je vais pouvoir me remettre au boulot.

Pour le die il y a 36 solutions pour couper ou transformer du texte. Pourquoi pas un include.....

La beta du week-end : HandCoder-b20060312

Avant de l'installer, vérifier le bug du <tabeditor> le plus gênant : ouvrir deux fichiers, puis rouvrir le premier de ces deux fichiers depuis le gestionnaire de sites. Celui-ci va se geler, le fichier est affiché dans l'onglet courant mais ne correspond pas à l'onglet qui est sélectionné.
Installer l'extension, refaire le même test, s'extasier (sans trop baver) si ça marche, faire un message d'insulte dans le cas contraire...

HandCoder utilise désormais ".(nom_fichier).html" comme fichier temporaire, ce qui devrait les masquer sous Linux (à vérifier, j'étais sous Windaube tout le week-end).

Pour les fichiers que HandCoder ne peut pas éditer dans Nvu (cf. die('</body></html>');), il les ouvre désormais dans l'éditeur texte.
Corollaire : il y a deux nouvelles préférences pour spécifier les extensions de fichier à ouvrir avec Nvu et l'éditeur texte respectivement. Ces préférences seront partagées avec la prochaine version de NsmConText.

L'indentation des scripts PHP est toujours perdue ; je suis bien conscient que c'est un (gros) problème, je m'y collerai pour les prochaines versions. En attendant, éviter l'onglet "Source", ou placer les scripts de plus d'une ligne dans des fichiers externes.

Bon test !

Kaze a écrit :vérifier le bug du <tabeditor>

Ok ca marche pour les onglets Normal, Balises HTML, Apercu. Pour l'onglet source ca reste coincé sur le dernier source affiché alors que en haut dans la barre c'est bien le dernier fichier ouvert qui est censé etre actif. Et effectivement quand on clic sur un autre onglet on tombe bien sur le dernier fichier ouvert.

File extension c'est tout en anglais. On va dire que c'est normal.

Le reste on verra demain.

Kaze a écrit :La beta du week-end : HandCoder-b20060312

Avant de l'installer, vérifier le bug du <tabeditor> le plus gênant : ouvrir deux fichiers, puis rouvrir le premier de ces deux fichiers depuis le gestionnaire de sites. Celui-ci va se geler, le fichier est affiché dans l'onglet courant mais ne correspond pas à l'onglet qui est sélectionné.
Installer l'extension, refaire le même test, s'extasier (sans trop baver) si ça marche, faire un message d'insulte dans le cas contraire...

AAAAAAaaaaaaahhhhhhhh!!!!!

bave, bave, bave!!

HandCoder utilise désormais ".(nom_fichier).html" comme fichier temporaire, ce qui devrait les masquer sous Linux (à vérifier, j'étais sous Windaube tout le week-end).

Zut, je viens de switcher sur Win2k suite à des soucis pour installer NVU sous FC4. Vais revoir ça demain.

Pour les fichiers que HandCoder ne peut pas éditer dans Nvu (cf. die('</body></html>');), il les ouvre désormais dans l'éditeur texte.
Corollaire : il y a deux nouvelles préférences pour spécifier les extensions de fichier à ouvrir avec Nvu et l'éditeur texte respectivement. Ces préférences seront partagées avec la prochaine version de NsmConText.

Ben, moi j'ai la zone
"Editeur de texte" -> Chemin de l'exécutable: vide. Mmmhhh???
"File Extensions" -> Open in HTML mode: htm,html,shtml,xhtml,php
-> Open in texte mode: txt,text,js
Double clic sur un nom de fichier .php m'ouvre Scite.
La console me donne:

Code : Tout sélectionner

KazIO: started application 'D:\Program Files\SciTe\SciTE.exe' on 'W:\sio2\ecrire.php'

J'ai dû rater une marche quelque part. Croc-en-jambe avec une autre extension?

L'indentation des scripts PHP est toujours perdue ; je suis bien conscient que c'est un (gros) problème, je m'y collerai pour les prochaines versions. En attendant, éviter l'onglet "Source", ou placer les scripts de plus d'une ligne dans des fichiers externes.

Bon test !

Promis, je ne touche pas à l'onglet source.

Parole d'ivrogne. Je sors d'en prendre.
Ca donne ça:

Code : Tout sélectionner

  <title>M'&eacute;crire</title>
<?php //  la variable $mail contient l'adresse e-mail
     include ("mail.inc.php");
     $confirme = isset($_REQUEST['confirme']) ? $_REQUEST['confirme'] : Null; 
...
     ?>

L'indentation n'est pas perdue... Juste la première ligne. J'avais écrit

Code : Tout sélectionner

  <title>M'&eacute;crire</title>
<?php
 //  la variable $mail contient l'adresse e-mail
     include ("mail.inc.php");
     $confirme = isset($_REQUEST['confirme']) ? $_REQUEST['confirme'] : Null; 
...
     ?>

Pour rappel: Win2k, Handcoder, Lorem Ipsum, NsmContext, KazCades, UrlCleaner, Nvu Tutorial

Ymai a écrit :Zut, je viens de switcher sur Win2k suite à des soucis pour installer NVU sous FC4. Vais revoir ça demain.
"Editeur de texte" -> Chemin de l'exécutable: vide. Mmmhhh???

J'ai aussi remarqué le chemin vide pour l'editeur mais comme je viens de faire mon deuil de scite j'ai pensé de ca devait venir de moi. Bref j'ai remis mon editeur favoris sous windaube (crimson).
J'espere que ca marche sur tous les OS le coup du point devant.

Je crois qu'il a aussi perdu le chemin de tidy.
Il a aussi perdu le bouton Editeur

Code : Tout sélectionner

Erreur : gToolbox.toolbarset has no properties
Fichier source : chrome://global/content/customizeToolbar.js
Ligne : 172

Quand je le remets

En fermant mes onglet j'ai plein de

Code : Tout sélectionner

Erreur : uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIEditingSession.setEditorOnControllers]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://editor/content/bindings/tabeditor.xml :: SelectTabEditor :: line 310"  data: no]

Fragment qui s'ouvre automatiquement dans l'editeur > Impossible d'enregistrer le fichier. Plein de MFCx.tmp vides dans le repertoire.

Le critere apparement c'est la detection des balise body html. En le decoupant ca souvre bien avec nvu. Vu qu'il y a d'autre facon d'ecrire ca dans le code je ne sais pas si c'est necessaire de pourir ton code pour ce cas. Peut-etre qu'une detection/avertissement/convertion serait une autre solution ?

Bon finalement c'est que le chemin vers l'editeur texte qui a disparu. Le reste est encore là. (sur une 3eme machine)

[humour]Au fait je t'ai dejà dit que htmlheader mets un rouleau de papier toillette pour ta balise d'entete.

[/humour]

Est-ce que tu peux mettre l'onglet source en lecture seul ? Histoire de pas detruire l'indentation php.

Do-IT a écrit :
Kaze a écrit :vérifier le bug du <tabeditor>
Ok ca marche pour les onglets Normal, Balises HTML, Apercu. Pour l'onglet source ca reste coincé sur le dernier source affiché [...]

Argh j'ai encore oublié cet onglet "Source". A corriger.

Do-IT a écrit :En fermant mes onglet j'ai plein de
Code : Tout sélectionner
Erreur : (NS_ERROR_INVALID_POINTER) tabeditor.xml :: SelectTabEditor :: line 310

Oui

et c'est déjà le cas sans HandCoder.
C'est ce qui arrive quand on ferme le dernier onglet (tabeditor perd son indexation). On obtient alors la même erreur chaque fois qu'on clique sur un onglet, jusqu'à ce qu'on crée un nouvel onglet. Ca sera très difficile à corriger via une extension...
Par contre, je ne sais pas si ça a des répercussions sur le fonctionnement de Nvu.

Do-IT a écrit :File extension c'est tout en anglais. On va dire que c'est normal.

C'est temporaire, si je peux m'en passer et n'avoir ces paramètres que sous NsmConText, ça m'irait bien.

Ymai a écrit :"Editeur de texte" -> Chemin de l'exécutable: vide. Mmmhhh???

La préférence où est stockée le chemin de l'éditeur texte a été changée, pour être dans une zone partagée entre HandCoder et NsmConText.

Ymai a écrit :Double clic sur un nom de fichier .php m'ouvre Scite.

Ca prouve que NsmConText fonctionne bien

C'est la raison pour laquelle je vais devoir sortir une version de NsmConText en même temps que la 0.3.2 de HandCoder. Le type "Scripts serveur" va disparaître, on n'aura plus que des documents HTML (au sens large) et des fichiers texte (ouverts directement par l'éditeur texte).

Do-IT a écrit :Fragment qui s'ouvre automatiquement dans l'editeur > Impossible d'enregistrer le fichier. Plein de MFCx.tmp vides dans le repertoire.

Je suppose que tu parles d'un fragment non-éditable (die "</body></html>") qui s'ouvre dans l'éditeur texte ? Qu'est-ce qui t'empêche de le sauvegarder dans ce cas-là ?
Il y a d'autres cas que celui-là où le fragment ne sera pas éditable par Nvu + HandCoder, donc je crois qu'il est nécessaire de prévoir le cas où HandCoder devra lancer l'éditeur texte. Même si ce cas-là est un peu "tordu".

Do-IT a écrit :Au fait je t'ai dejà dit que htmlheader mets un rouleau de papier toillette pour ta balise d'entete.

Il aime pas les commentaires ou les pseudo-instructions PHP dans l'en-tête... j'avais constaté. Si Simon poursuit le développement de HTML Header, je l'aiderai à implémenter ça.

Do-IT a écrit :Est-ce que tu peux mettre l'onglet source en lecture seul ? Histoire de pas detruire l'indentation php.

Probablement... mais je préfère bosser sur la non-destruction de l'indentation des scripts d'abord. Si je n'y arrive pas, je mettrai une option "lecture seule" pour cet onglet. En attendant, je signalerai ça comme un bug de l'éditeur non résolu par HandCoder.

Kaze a écrit :Je suppose que tu parles d'un fragment non-éditable (die "</body></html>") qui s'ouvre dans l'éditeur texte ? Qu'est-ce qui t'empêche de le sauvegarder dans ce cas-là ?
Il y a d'autres cas que celui-là où le fragment ne sera pas éditable par Nvu + HandCoder, donc je crois qu'il est nécessaire de prévoir le cas où HandCoder devra lancer l'éditeur texte. Même si ce cas-là est un peu "tordu".

L'enregistrement dans l'editeur externe est tout simplement impossible. => L'acces a un fichier non nommé à été refusé.
Je crois que c'est la poisse ! Ca me le fait pas avec scite et notepad ! Juste avec mon editeur favoris

Ahhhh ! avec wordpad comme editeur (C:\Program Files\Windows NT\Accessoires\wordpad.exe) ca me fait aussi un caca nerveux => Le document ... est utilisé par une autre application et n'est pas accessible. Je suis pas si maudit que ca.

La beta du jour : HandCoder-b20060313

Wordpad accepte désormais de sauvegarder un fichier "tordu".
L'onglet "Source" ne perturbe plus la correction de bug que j'ai faite sur le <tabeditor> (mais les erreurs à la fermeture du dernier onglet demeurent).
L'option "Relativiser les URLs externes" a été intégrée dans le nettoyeur de balises. URL Cleaner devient donc 100% inutile pour ceux qui ont installé HandCoder + KaZcadeS.

Je crois que je vais devoir garder les deux nouvelles préférences dans HandCoder, je ferai la localisation pour la prochaine version.

PS: Je viens de voir un bug que je n'avais pas remarqué jusque-là : la fenêtre "fichier modifié" apparait après une sauvegarde, si on clique dans une autre fenêtre avant de revenir dans Nvu. Je ne sais pas si c'est systématique.

Geckozone

HandCoder : extension Nvu pour Tidy et PHP