> pourquoi Nvu s'embete-t-il a modifier du code dont je n'ai pas touché en wysiwyg? Il ne peut pas le laisser tranquille?
Il s'embete pas à modifier le code, il ne peut pas faire autrement, tout simplement. Et il peut pas le laisser tranquille
Quand tu edites une page HTML en wysiwyg : le fichier est parsé et transformé en arbre DOM. Cette opération est indispensable pour que Gecko puisse l'afficher. Ensuite, quand tu édites, ajoutes, modifie des trucs, cela fait des manipulations sur le DOM, pas sur le source. Quand tu bascules en source ou que tu enregistres le fichier, il y a serialisation du DOM. C'est ce qu'il y a de plus simple, et je t'assure, c'est déjà assez compliqué comme ça. Faut bien comprendre qu'un editeur HTML/XML wysiwyg ne travaille absolument pas sur le source, mais sur une representation logicielle de la structure du document (le DOM). On ne peut faire autrement à cause de l'aspect Wysiwyg. Si on travaillait directement sur la source, le rendu serait beaucoup trop lent. à chaque modif (du copier d'un bloc, à l'insertion d'un seul caractère), faudrait déjà placer la modif au bon endroit (donc trouver la balise qui correspond, changer ce qu'il y a à changer dans le source) et ensuite re-parser le source, re-interpreter les balises, et re-appliquer les styles CSS, re-faire l'affichage en conséquence etc... Ce serait, contrairement à ce que tu dis, bien plus embetant que de faire comme c'est fait actuellement. Quant à maintenir une version à la fois textuel et DOM en mémoire, ce serait d'une complexité totalement futile.
Si il fallait en plus, lors de la serialisation, remettre tout en place comme c'etait avant, cela necessiterait donc de mémoriser l'emplacement de chaque caractère, de chaque balise, de mémoriser ce qui a été modifié, ce qui ne l'a pas été, d'éventuellement tenir compte de preferences utilisateurs sur la façon de formater les nouveaus trucs etc... Bonjour alors l'occupation mémoire, les perfs et la complexité du truc. Pour un résultat finalement *vraiment* peu utile.
> Et non, désolé, je ne participerai pas, j'ai déja mon projet qui me bouffe du temps
C'étais ironique ce que je disais, car faire les modifs que tu demandes, demanderait de modifier le moteur Gecko, ce qui te prendrait des mois à le faire (à plein temps), le temps de comprendre comment ça fonctionne... (et tu perdrais ton temps car tu comprendrais que c'est finalement pas interressant de le faire, vu ce que cela impliquerai en terme de coût mémoire, perf etc.. et les conséquences sur tout le reste). C'est pour plein de bonnes raisons que ce n'est pas fait dans Nvu.. Et plein de bonnes raisons qui fait que ces modifs ne seraient pas acceptés par la fondation Mozilla (à toi donc de maintenir ton patch avec chaque version de Gecko, ce qui est trés contraignant et perte de temps...).
[^] # Re: Reformatage du code
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 10.
Il s'embete pas à modifier le code, il ne peut pas faire autrement, tout simplement. Et il peut pas le laisser tranquille
Quand tu edites une page HTML en wysiwyg : le fichier est parsé et transformé en arbre DOM. Cette opération est indispensable pour que Gecko puisse l'afficher. Ensuite, quand tu édites, ajoutes, modifie des trucs, cela fait des manipulations sur le DOM, pas sur le source. Quand tu bascules en source ou que tu enregistres le fichier, il y a serialisation du DOM. C'est ce qu'il y a de plus simple, et je t'assure, c'est déjà assez compliqué comme ça. Faut bien comprendre qu'un editeur HTML/XML wysiwyg ne travaille absolument pas sur le source, mais sur une representation logicielle de la structure du document (le DOM). On ne peut faire autrement à cause de l'aspect Wysiwyg. Si on travaillait directement sur la source, le rendu serait beaucoup trop lent. à chaque modif (du copier d'un bloc, à l'insertion d'un seul caractère), faudrait déjà placer la modif au bon endroit (donc trouver la balise qui correspond, changer ce qu'il y a à changer dans le source) et ensuite re-parser le source, re-interpreter les balises, et re-appliquer les styles CSS, re-faire l'affichage en conséquence etc... Ce serait, contrairement à ce que tu dis, bien plus embetant que de faire comme c'est fait actuellement. Quant à maintenir une version à la fois textuel et DOM en mémoire, ce serait d'une complexité totalement futile.
Si il fallait en plus, lors de la serialisation, remettre tout en place comme c'etait avant, cela necessiterait donc de mémoriser l'emplacement de chaque caractère, de chaque balise, de mémoriser ce qui a été modifié, ce qui ne l'a pas été, d'éventuellement tenir compte de preferences utilisateurs sur la façon de formater les nouveaus trucs etc... Bonjour alors l'occupation mémoire, les perfs et la complexité du truc. Pour un résultat finalement *vraiment* peu utile.
> Et non, désolé, je ne participerai pas, j'ai déja mon projet qui me bouffe du temps
C'étais ironique ce que je disais, car faire les modifs que tu demandes, demanderait de modifier le moteur Gecko, ce qui te prendrait des mois à le faire (à plein temps), le temps de comprendre comment ça fonctionne... (et tu perdrais ton temps car tu comprendrais que c'est finalement pas interressant de le faire, vu ce que cela impliquerai en terme de coût mémoire, perf etc.. et les conséquences sur tout le reste). C'est pour plein de bonnes raisons que ce n'est pas fait dans Nvu.. Et plein de bonnes raisons qui fait que ces modifs ne seraient pas acceptés par la fondation Mozilla (à toi donc de maintenir ton patch avec chaque version de Gecko, ce qui est trés contraignant et perte de temps...).