Page 22 sur 24
Publié : 19 mai 2006, 11:24
par Kazé
Quels autres utilisateurs ? Franchement, à part Ymai, chinon et toi...
La 0.3.2 est bien buggée : la détection des fichiers modifiés ne fonctionne pas, impossible d'enregistrer en UTF-8, et dans certains cas on perdait du PHP. Je commence à recevoir pas mal de mails d'utilisateurs qui constatent les bugs de la 0.3.2 ; la 0.3.3 ne peut qu'être meilleure...
De toutes façons, ça n'est qu'une version intermédiaire, puisqu'il faut encore que je modifie la gestion des prologues et que j'implémente le support des balises courtes <% %>, ce qui suppose des modifs assez lourdes ; donc il faut que je fige l'état courant avant de trafiquer le code.
Publié : 19 mai 2006, 13:34
par Kazé
J'attaque la 0.3.4. Le premier objectif serait de supporter ce prologue :
Code : Tout sélectionner
<?php echo "<?xml version=\"1.0\"?>"; ?>
<?php defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not allowed.' ); ?>
J'ai modifié hc pour qu'il puisse accepter plusieurs blocs comme prologue. Ca marchouille.
Par contre, avec Tidy on a un gros problème : la ligne
plante Tidy lamentablement. Comme Nvu (et la plupart des parsers html/xml), Tidy s'arrête au premier ?> qu'il trouve, ce qui détruit le document...
On ne peut pas non plus (semble-t'il) utiliser un prologue plus simple, du style :
Code : Tout sélectionner
<?xml version="1.0"?>
<?php defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not allowed.' ); ?>
car le parser PHP interprète le
<?xml comme un début d'instruction PHP. C'est parfaitement idiot mais ça explique pourquoi la ligne
echo "<?xml version=\"1.0\"?>" est si courante. Ca n'est probablement plus vrai avec PHP5, puisque la forme courte <? ... ?> n'est plus autorisée.
Alternatives pour contourner ce bug :
- <?php echo "<?xml version=\"1.0\"?" . ">"; ?>
- <?php include('xmlprolog.txt'); ?>
- utiliser hc030, qui stocke le prologue dans un fichier texte séparé (ce qui ralentit sensiblement chaque sauvegarde)
- ne pas utiliser Tidy (mais franchement, un fichier PHP édité par Nvu et pas reformatté par Tidy, ça doit pas être simple à éditer...)
Si quelqu'un a une idée, merci d'avance...
Publié : 19 mai 2006, 15:21
par Do-IT
Kaze a écrit :<?php echo <?xml version="1.0"?>"; ?>
Dans tous tes codes il manque un " après le echo. (ca fait des parse error dans ma tête)
La première solution me semble être la moins compliqué (quoi que).
On récupère la chaîne à afficher qui commence après le echo et qui se termine par ; "<?xml version="1.0"?>"
on isole les ? (il faut détecter le type de guillemet)
"<"."?"."xml version="1.0""."?".">"
'<'.'?'.'xml version="1.0"'.'?'.'>'
ou on remplace les ? par %c et on met la chaîne dans un sprintf
sprintf("<%cxml version="1.0"%c>", 63)
ce qui donne
<?php echo sprintf("<%cxml version="1.0"%c>", 63); ?>
Jamais utilisé, ca reste de la pure théorie. Je connais cette
fonction depuis 1 minute. En html ça devrait afficher
<?xml version="1.0"?>
Publié : 19 mai 2006, 19:20
par Kazé
J'ai corrigé les echo
Do-IT a écrit :qui commence après le echo et qui se termine par ;
Bonsanmécébiensûr !
Il suffit de scinder les chaînes ?> qui suivent les echo et de laisser les autres tranquilles.
Pour la détection du guillemet, on doit pouvoir considérer que c'est celui qui suit le echo qui est utilisé sur toute la ligne. Evidemment c'est plantable avec une ligne du type :
mais de toutes façons, aucun parser html ou xml ne sera jamais 100% sûr pour éditer du PHP, donc on peut se cantonner aux cas les plus fréquents.
Sinon, je viens de déterrer TidyLib. Il y a peut-être une solution en bricolant de ce coté-là, car je pourrais reformatter le code en mémoire vive plutôt que sur le disque dur. Du coup je pourrais reformatter le code sans le prologue, puis ajouter le prologue et sauvegarder...
Le problème, c'est que j'ai déjà perdu pas mal de pages avec TidyLib, sans comprendre pourquoi. C'était peut-être lié aux problèmes d'encodage des versions < 0.3.3, ça mérite quelques tests supplémentaires.
PS: TidyLib transforme le HTML 4.01 Strict en Transitional...
Publié : 19 mai 2006, 20:57
par Do-IT
Kaze a écrit :Evidemment c'est plantable avec une ligne du type :
D'où le quoi que. Mais on peut faire plus simple :
Tu pourra pas te passer de la détection des guillemets.
Le sprintf à l'air plus blindé
<?php echo sprintf('<?xml version="1.0"'."%c>", 63); ?> (Testé, ca fonctionne)
Pas besoin de détecter les guillemets.
Il y a sûrement une meilleure solution que d'ajouter une fonction php que ce soit sprintf ou une autre.
Autre solution dont je ne suis pas convaincu :
<?php echo "<?xml version="1.0"?".chr(62); ?>
Kaze a écrit :Sinon, je viens de déterrer TidyLib
hc0.3.9b. Onglet source me donne une fenetre d'alerte Prettyprint:true
F7 aussi. Avec une preview de code source. On va dire que c'est normal.
Vu que j'ai toujours tidy de configurer il utilise pas tidylib, je pense. Idem
pour Strict en Transitional
Publié : 19 mai 2006, 22:50
par Kazé
Le sprintf est une bonne idée. C'est clairement plus robuste, c'est même un peu plus simple à coder, mais j'ai peur que ça ne perturbe les utilisateurs ; alors qu'en scindant les ?>, je parie que la plupart ne verront pas la modification.
Do-IT a écrit :hc0.3.9b.
Bah ça m'apprendra à stocker mes versions de travail sur mon site web ! (j'avais oublié ma clé USB...)
Tu noteras que ça préserve n'importe quel prologue...
Do-IT a écrit :Vu que j'ai toujours tidy de configurer il utilise pas tidylib, je pense.
TidyLib est lancé lors de chaque sauvegarde, mais c'est presque trop rapide pour qu'on s'en rende compte.
"prettyPrint" correspond à l'état de la préférence Nvu "reformatter la source HTML". L'idée serait de ne lancer TidyLib que si "prettyPrint" est vrai...
Publié : 19 mai 2006, 23:35
par Do-IT
Une site web c'est vaste, là c'était le dossier 'officiel'.
Donc j'ai installé la 0.3.3rc4, et là j'ai eu une crise cardiaque. Il y a eu une page intermediaire qui est resté affiché 1 seconde (avec des barres de progression qui défilent) puis
ça. Ce qui est bizarre c'est que j'ai rien demandé, et j'ai jamais cliqué sur Mise à jour. On va dire que c'est normal. (Que le mise à jour se soit lancée toute seule)
Bon après ces moments chargés en émotions, on va repassé aux choses sérieuses.
Publié : 20 mai 2006, 11:29
par Kazé
La rc4 vient de devenir la
version 0.3.3 'officielle'. Je mettrai mon site web à jour dans le week-end.
La 0.3.4 devrait arriver rapidement (nouvelle gestion des prologues + support ASP/JSP). Ca commence à devenir stable tout ça...
Do-IT a écrit :Une site web c'est vaste, là c'était le dossier 'officiel'.
Je viens de mettre des "Deny all" dans les dossiers xpi 'officiels'.
Do-IT a écrit :Donc j'ai installé la 0.3.3rc4, et là j'ai eu une crise cardiaque.
Nvu ne doit pas aimer quand on repasse à une version antérieure d'une extension. Bizarre.
Ca me rappelle qu'il faudrait que j'implémente la mise à jour automatique pour mes extensions !
Publié : 24 mai 2006, 12:22
par Do-IT
hc0.3.3
C'est des vieux bug, mais j'en reparle un peu :
- le code php subit 'toujours encore' un décalage lors de chaque lancement de tidy, à partir de la 2eme ligne de code php. (idem sous xp & linux)
- Si on faire une modif dans nvu dans l'onglet source, le code php se retrouve sur une ligne. (idem sous xp & linux). C'est pour ca que j'ai viré la barre d'outils Mode d'édition sur mon nvu de 'travail'.
Publié : 24 mai 2006, 15:47
par Kazé
Do-IT a écrit :le code php subit 'toujours encore' un décalage lors de chaque lancement de tidy, à partir de la 2eme ligne de code php. (idem sous xp & linux)
Ca avait été partiellement résolu avec la 0.3.2, mais ça créait d'autres bugs liés à la gestion du prologue (cf. le thread d'Ymai).
Si on lance Tidy plusieurs fois de suite, ça augmente le décalage des scripts PHP. Par contre, si on lance Tidy à la sauvegarde, le décalage reste stable.
En lançant TidyLib uniquement à la sauvegarde, ça résoudrait ce problème, celui des prologues, et plus généralement ça permettrait d'envisager le support de balises non HTML comme SPIP, MathML...
Do-IT a écrit :Si on faire une modif dans nvu dans l'onglet source, le code php se retrouve sur une ligne. (idem sous xp & linux).
Oui, idem pour les balises <pre>, même sans HandCoder.
C'est pénible. C'est même dangereux quand on utilise des commentaires de fin de ligne (//) plutôt que des blocs (/* */).
J'ai essayé de corriger ça mais je n'y suis pas arrivé.
Là encore, en intégrant TidyLib il y a peut-être moyen de résoudre le problème.
Publié : 28 mai 2006, 17:52
par Do-IT
Kaze a écrit :En lançant TidyLib uniquement à la sauvegarde, ça résoudrait ce problème, ...
J'ai mis Tidy (pas lib) à la sauvegarde + nettoyeur, on va voir ce que ça donne.
Le bouton éditeur n'est compatible avec aucun des 4 autres
thèmes. Ça donne toujours une superposition de 3 boutons éditeur.
Publié : 28 mai 2006, 19:22
par chinon37
les précédentes versions posaient le même probléme avec les autres thèmes...
Publié : 30 mai 2006, 14:08
par Do-IT
Do-IT a écrit :Tiens j'ai encore un code php qui disparaît à 100%, merci nvu. (à suivre... dans l'autre sujet...)
On a sûrement déjà parlé de la forme courte des balises php ?
Bref, dans le temps j'utilisais ça.
Nvu seul n'apprécie pas, il supprime tout.
nvu+hc, pareil.
nvu+nsm, là c'est bizarre ça ouvre rien
Code : Tout sélectionner
Erreur : window.top.document.open is not a function
Fichier source : chrome://nsmcontext/content/sitemanagerOverlay.js
Ligne : 121
Seul Kaze saura pourquoi j'ai mis ça dans ce sujet.
Publié : 31 mai 2006, 09:22
par Kazé
Le bouton "Editeur" ne fonctionne bien qu'avec le thème par défaut. J'ai commencé à regarder pourquoi, mais je n'ai pas trouvé de solution simple pour l'instant.
Do-IT a écrit :On a sûrement déjà parlé de la forme courte des balises php ?
Effectivement, c'est une régression sur hc030. Bêtement, la forme <% %> est bien lue par hc033 (qui les transforme en <?php ?>)...
A corriger. Il devrait y avoir une beta ces jours-ci avec un (petit) support ASP/JSP.
Publié : 31 mai 2006, 09:47
par Do-IT
Kaze a écrit :Il devrait y avoir une beta ces jours-ci avec un (petit) support ASP/JSP.
Avec Tidylib et support des
include ?
JSP je savais même pas que ça existait.
