[Texmacs-dev] Re: Convention stage

[Joris van der Hoeven]

On Thu, 4 Apr 2002, David Allouche wrote:

> 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.

La plupart des arbres dans TeXmacs sont en faite des arbres correspondant
a des documents donc en quelque sorte des arbres sources d'eux-memes.
On pourrait eventuellement choisir de les stocker une seule fois au lieu
de deux fois. De toute facon un arbre habituel peut toujours etre vu comme
un arbre avec source, pour lequel toutes les etiquettes sont NULL.

> > > 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. 

Bon, si tu veux, mais ne tardes pas trop a coder tout ceci.

> > > 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.

Par mise en page, j'entends tout le processus de mis en page, y compris
le "shoving" et le "filling". Dans le futur, toute la mise en page sera
paresseux ; il n'y aura donc plus de veritable distinction entre
la production d'une boite ou de plusieurs boites a etre assemblees
par la suite.

> 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)?

Probablement non (enfin, on souhaite obtenir une longueur plutot qu'uneespace),
mais je ne suis pas 100% sur. De toute facon, si on travaille avec des arbres
(ou eventuellement des boites), ce n'est pas vraiment un probleme.

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

C.a.d.?

>  -- 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.

Il faudrait que je replonge un peu dans le code pour te renseigner avec
precision sans dire de conneries.