Bonjour,
Toujours dans les idées par rapport à la remarque d'Emmanuel que son truc,
c'est les langages.
Actuellement, les raccourcis typographiques sont gérés par des regexp qui
deviennent de plus en plus difficiles à gérer (avec des bugs induits par des
cas non prévus).
Avec une grammaire et un analyseur syntaxique, ce genre de difficultés
pourrait disparaitre.
D'autre part, le rajout d'un raccourcis typographique se ramènerait à
l'ajout d'une règle dans la grammaire (en caricaturant).
Qu'en pensez-vous ?
Emmanuel, tu avais besoin de projet pour tes étudiants cette année ?
Cordialement,
Je suis surpris par absence de réaction.
Je n'ai pas été clair dans mon explication ?
Je suis à des années lumières des préoccupations du moment ?
Personne n'en perçoit l'intérêt ?
Ou l'inverse, ça paraît tellement évident que ce n'est même pas la peine de
le dire ?
Jacques PYRAT wrote:
Le mieux si personne ne répond et que tu penses que l'idée est bonne,
c'est de faire une étude ou un prototype et de présenter les résultats.
Ton idée est à la fois trop floue et ambitieuse pour l'expédier en cinq
minutes sur une liste de discussion.
Amicalement
Antoine.
Antoine wrote:
Je suis surpris par absence de réaction.
Je n'ai pas été clair dans mon explication ?
Je suis à des années lumières des préoccupations du moment ?
Personne n'en perçoit l'intérêt ?
Ou l'inverse, ça paraît tellement évident que ce n'est même pas la
peine de le dire ?
Le mieux si personne ne répond et que tu penses que l'idée est bonne,
c'est de faire une étude ou un prototype et de présenter les
résultats. Ton idée est à la fois trop floue et ambitieuse pour
l'expédier en cinq minutes sur une liste de discussion.
Merci pour cet éclaircissement.
Malheureusement, je suis incapable de réaliser un compilateur (contrairement
à Emmanuel).
Or, ce dont je parle, c'est d'un compilateur pour le langage de typo de
SPIP.
Intérêts ?
- ne plus avoir besoin d'échaper certains nouveaux raccourcis durant les
traitements pour qu'ils ne soient pas transformés par le reste
- pouvoir gérer le XHTML 2 quand il sortira par simple mise à jour de la
grammaire 
- Disposer de 2 grammaires : HTML et XHTML (et se passer de Tidy)
- Pouvoir étendre facilement la grammaire à de nouveaux raccourcis typo sans
tout casser
- Avoir des messages d'erreur sur les raccourcis typo (genre raccourcis non
fermé, ou raccourcis interdit à l'intérieur de tel autre).
- ...
Durant mes études, notre prof de compilateur nous avait attiré l'attention
sur le fait qu'un traitement de texte utilise un compilateur pour produire
l'affichage (de même pour un navigateur web).
J'ai fait l'impasse sur le codage d'un compilateur, mais j'ai retenu au
moins ça : un compilateur, c'est un traducteur depuis un langage source vers
un langage cible.
Or, que sont les raccourcis typo ? Un langage (descriptif).
Et le HTML généré ? Un langage aussi.
Amicalement
Antoine.
@+
Durant mes études, notre prof de compilateur nous avait attiré l'attention
sur le fait qu'un traitement de texte utilise un compilateur pour produire
l'affichage (de même pour un navigateur web).
J'ai fait l'impasse sur le codage d'un compilateur, mais j'ai retenu au
moins ça : un compilateur, c'est un traducteur depuis un langage source vers
un langage cible.
So what ? Dans ce cas, la fonction propre() actuelle est aussi un
"compilateur", et on n'en parle plus.
Ce que tu veux, c'est un compilateur meilleur que l'actuel.
Précisément : 1) avec une grammaire plus rigoureuse 2) tout en étant
aussi rapide que l'actuel.
J'ai des raisons de douter que ce soit aisé, étant donné que la rapidité
du propre() actuel vient du fait qu'il utilise un maximum de fonctions
natives (preg_replace, etc.). Si tu codes ta propre grammaire complexe,
tu vas avoir un mal de chien à la faire entrer dans un nombre limité
d'expressions régulières. Et si tu fais les recherches / remplacements
en PHP, les performances vont s'écrouler.
Mais, dans tous les cas, même si le dit "compilateur" n'est jamais
écrit, tu peux quand même concevoir (wiki...) une grammaire idéale des
raccourcis, cela pourra de toute façon servir comme référence.
a+
Antoine.
Sorry. Le sujet m'interesse, mais j'ai un peu la tête sous l'eau
en ce moment.
J'ai commencé à potasser le problème il y a quelques temps, notamment
pour plusieurs raisons :
- la fonction propre génère des trucs moyennement propres dans certains
cas, et c'est infernal d'essayer d'y mettre les mains
- pas mal d'idées de raccourcis supplémentaires ont été proposées sur
le lab, et là aussi ça risque d'être coton à coder vu la tronche
du code actuel
- le code actuel contient des appels dans tous les sens, et il est
très dur à isoler du reste. Donc, difficile de faire par exemple un
spikini autrement qu'en référençant pleins de fichiers de spip.
Maintenant, définir une grammaire des raccourcis, c'est pas immédiat.
Le faire en bnf ou autre, déjà c'est pas facile (quelles sont les
imbrications autorisées ou non notamment), mais le faire d'une façon
utilisable en php, c'est l'enfer, puisqu'il n'y a pas d'équivalent php
de lex et yacc ou autre bison ou cocktail.
J'ai commencé à faire ça avec mon parseur maison (celui que Antoine à
baptisé Placid), mais je suis loin d'être au bout, et je ne sais pas
du tout si les perfs seront là.
Ce qui n'arrange rien, c'est qu'on a pas mal d'éléments de la
grammaire qui sont mal bornés : les paragraphe sont séparés, et pas
encadrés, les listes à puces ne sont marquées que par les débuts
d'items et non encadrées ...
Exemple :
blabla
- blabla
_ blabla
blabla
- bloblo
Est-ce que c'est une liste de 2 item dont un contient 2
paragraphes ou 2 listes séparées par un paragraphe ?
En tous cas, il y a de quoi alimenter le débat sur le lab, et dès que
j'ai un peu de mou, je me remettrai sur ce sujet. Il y a déjà un
"article de référence" dans le spip du lab qui peu servir à faire des
tests, et sur le cvs, il y a un bout de code php qui peut servir à
comparer la fonction propre à une autre version (diff du résultats
+ timing) => à suivre sur la liste lab
À+, Pif.