[Texmacs-dev] Re: Convention stage

[David Allouche]

On Thursday 04 April 2002 10:51, Joris van der Hoeven wrote:
> > > P.S. : tu as commence deja un peu ?
> >
> > Oui je suis en train de travailler sur une RFC informelle ou j'ai posees
> > toutes mes idee pour m'aider a y voir plus clair et ou j'ai cherche a
> > comprendre ce que tu voulais.
> >
> > Je pense que j'ai bien compris ce a quoi tu pense avec stree et dtree.
>
> J'ai rereflechi un peu a la question.
> Il se pourrait meme etre preferable dans le futur que
> la classe "tree" habituelle devienne un "stree".
> En tout cas, commencons par separer les deux ;
> si tout fonctionne on pourra toujours en faire une seule classe.

La, par contre, je ne suis plus du tout.

La class stree devrait permettre d'avoire la "matiere premiere" necessaire a 
la creation de dtree: des fragments positionnes. Comme stree maintient des 
inverse path a jour pour tout ses noeuds, je ne vois pas en quoi elle peut 
etre utile ailleurs que pour l'arbre source.

> > J'ai mis le doigt recemment sur un concept interessant: bridge serai une
> > concretisation du fil d'execution. Actuellement dans TeXmacs, ce fil est
> > tres proche de la structure combinee document+style, et de la structure
> > de boites, mais avec XSL ca risque d'etre un autre histoire.
> >
> > Je voudrais definir un API/protocole clair pour les transformations de
> > maniere a pouvoir utiliser la meme infrastructure pour des
> > transformations implementees en C++ (tmsl), ou en script. Le protocole
> > serait (pour l'instant) base sur les septs operations, plus un operation
> > 'commit', de facon a permettre d'implementer des optimisations elaborees
> > memes avec des transformations en script.
>
> SI je te comprends bien, la principale chose que tu voudrais rajouter
> est la possibilite de traiter plusieurs evenements en un seul coup en
> creant une sorte de flux tampon pour les evenements ? La commande commit
> videra le tampon. Ca me parait une bonne idee. Je vois encore une autre
> possibilite dans la meme ordre des idees : permettre les changements
> les plus importants (proche du curseur) a prendre effet immediatement et
> les autres (remettre a jour un index) de facon retardee.

Tout a fait. J'avais deja ecrit cela.

> > D'ici quelques jours, je mettrai le document en ligne.
>
> Je prefere que tu le mettes en ligne apres que tu l'auras code.
> De toute facon, pour le moment ce ne devront qu'etre nous deux
> qui travaillons la-dessus. En revanche, tu peux m'envoyer le document.

Je ne vois vraiment pas le probleme a le mettre en ligne tot... Meme si nous 
ne sommes que deux a travailler dessus, le fait de tenir les autres 
developpeurs (ou utilisateurs interesses) au courant ne peut pas etre nefaste.

Au contraire, c'est motivant pour tout le monde de voir que les autres 
avancent dans leurs projets respectifs. Et des discussion de gestation 
publiques ne peuvent qu'augmenter la connaissance globale de la philosophie 
et du fonctionnement de l'application, condition importante au succes d'un 
projet libre.

Enfin, il ne s'agit pas d'un article scentifique fige, mais d'un document 
evolutif mis en ligne pour recevoir des suggestions interessantes. La 
genetique nous apprends que robustesse vient des croisements des lignees. De 
meme, en memetique, la robustesse vient du croisement des esprits. 

> > D'ici la je vais essayer d'eclaircir ces deux point et de commencer
> > a tracer la limite entre language typographique et TMSL.
>
> Je pense que la limite est assez simple : aucune instruction de scriptage
> (sauf les with pour les variables d'environnement standards) n'est valide
> apres reecriture.

Effectivement, mais ca merite quand meme d'etre mis au propre.

> Reste le probleme avec des calculs sur les longueurs
> invoque la derniere fois que nous avions dejeune ensemble.
> Pour ca je pense qu'il faudrait pouvoir forcer la mise en page lors
> de la reecriture ; l'alternative de reimplementer un language de scriptage
> au moment de la mise en page me parait trop lourde (on est precisement
> en train de s'en debarasser...). La commande de forcage pourrait
> donc etre une neuvieme commande dans l'API (sans arguments et rendant
> la boite ou (afin de limiter les dependances) avec un arbre en argument
> et un arbre avec l'information necessaire sur la boite en sortie).

J'ai souvent du mal a comprendre ce que tu entends par mise en page. Si je 
comprends bien, ici, tu parles de l'operation effectuee par la fonction 
typeset, qui produit un box a partir d'un tree, mai qui n'effectue aucune 
operation subsequente telles que la coupure, le "filling" et le "shoving" des 
lignes et des pages.

Ce qui me tracasse avec ce probleme est que y'a toujours plusieurs choses pas 
connectees dans mon esprit:

 -- y a-t-il des cas d'usages ou l'information desiree est plus complexe que 
un 'space' (espace elastique)?

 -- quelle approche pour ajouter des 'wide' non niches?

 -- je commence a saisir les grande ligne du processus de mise en page (de 
tree aux pages imprimables), mais beaucoup de choses apparemment importantes 
sont encore parfaitement mysterieuses pour moi; par exemple le role des 
marker.
-- 

                                  -- David --