Re: [Texmacs-dev] More comments on David's document

[Joris van der Hoeven]

On Thu, 11 Apr 2002, David Allouche wrote:

> On Wednesday 10 April 2002 17:39, Joris van der Hoeven wrote:
> > On Wed, 10 Apr 2002, David Allouche wrote:
> > >
> > > Naming and ptree
> > > ----------------
> > >
> > >     stree: stay as it is
> > >     ptree -> ttree (path tree -> tagged tree)
> > >     dtree -> rewriter
> > >
> > > ptree does not carry additional style information, it is just the tree
> > > type used in rewriters notifications. I separate stree and ttree, because
> > > the tagged trees only carry path information, while the source trees must
> > > also ensure each node path tag is equal to the actual inverse path of the
> > > node in the source tree. So tree operations on ttree will only rearrange
> > > the nodes (they will probably be cut'n'pasted from edit_modify) and stree
> > > operations will also update the inverse paths.
> >
> > OK, so please speak about "source ttrees" instead of "strees".
> > Indeed, "stree" is not a new data type, it is just a ttree with
> > a special purpose.
> 
> I think proper delegation mandates that stree be a subclass of ttree.
> The stree class extends the tree operations methods to update the inverse 
> paths.
> 
> Moreover ttree is a simple class encapsulating a data structure, but stree 
> implement in addition an observer registration interface, send notifications 
> on edition operations, and define a a "commit" method.
> 
> On the longer term, stree could also implement a complete transactional 
> interface, with concurrent access, locking and rollback. That would be useful 
> to allow real time collaborative editing of a document.

No, all these addional methods are part of the editor,
not of the source tree, which should really stay a *data* object.

> > > Observers
> > > ---------
> >
> > Like in the case of tree and stree, there is no real difference between
> > the rewriter, tree_observer and typesetter classes: they all refer to
> > the same abstract class.
> >
> > In the case of rewriter, tree_observer and typesetter,
> > I nevertheless feel that the difference in purpose is greater,
> > so you may use typedefs to let the different classes become synonyms.
> > (I also prefer "observer" to "tree_observer", since we will never
> > observe other types of objects). However, I am against doing
> > the same thing for "stree".
> 
> I really do not understand what you are thinking of when your are talking of 
> using "typedefs to let the different classes become synonyms". Why not simply 
> use inheritance with an abstract "observer" class which is implemented by 
> "rewritter" and "typesetter"???

I want typedefs for the moment, because this is faster.
I repeat: efficiency is a *major* design goal, whether you like that or not.
In any case, in the foreseeable future, these classes will be perfect synonyms,
which is better expressed using a typedef. If they ever turn out to be 
different,
then this can always be changed later.

> Edit tree
> ---------
> 
> I think there is a need for more terminology here. Since the current edit 
> tree is very overloaded and we are going to separate it in several parts, we 
> need more words.

You do not have to care about the edit tree anyway:
you care about the source tree.

> Let us call the tree which is fed to the typesetter the "object tree", and 
> say that a legal "object tree" respects the syntax of the "typesetting 
> language" of TeXmacs. 
> 
> I think that the behaviour of the editor must not be directly affected by the 
> source tree, but only by the object tree.

No: the source tree contains the structure; the object tree is only
obtained after rewriting and the boxes after typesetting.
The only sensible structure the editor operates on is the source tree.

> I see TeXmacs as an interactive 
> structured typesettng system. The typesetting system is made of a typesetter 
> tightly coupled with an editor. That means that the typesetting language not 
> only has primitives for layout, but also for controlling the editor.

Wrong: the typesetting language has no primitives whatsoever for
controlling the editor and this independence is a major advantage.
This does not withhold the editor to *communicate* with typesetted boxes,
in order to associate logical paths to physical positions or
to find a hyperlink associated to a region of text.
In other words, there is a clear separation between structure and
rendering on the implementation level.

> For example, it could be useful to decouple the region concept (as 
> implemented by varexpand) from the environment concept (as implemented by 
> most structures). A region affects only the typesetter, while an environment 
> also affect the editor (infinitesimal positions).

Yes, this will be a result of what you are doing.
We are working towards a clean separation of

1. Structure
2. Rewriting and/or scripting
3. Rendering

> Since the source tree structure is completely independant from the object 
> tree structure, we cannot rely on the source tree for controlling the editor. 
> Instead, the editor will only send edition notifications to the stree.

No, we can not rely on the object tree for controlling the editor,
because the structure of the object tree does not directly correspond to
the structure of the source tree, which we are editing.

> If we want to modify the behaviour of the editor according to the actual 
> structure of the source tree, we need another module, which I call the 
> "dynamic validator". That module would tell the user-interface what what are 
> the valid editing commands at a given point, and would be able to prevent the 
> editor from performing illegal editing transactions. By transaction I mean 
> that we will need a rollback ability since we cannot assume that any valid 
> editing command can be performed by passing by a completely valid path where 
> each step is an elementary tree operation.

Yes, that is the next step, which I already mentioned in a discussion:
I plan to incorporate DTD support in TeXmacs. At that point we will have
four levels:

1. DTD and validated logical trees
2. Brute non validated trees (source trees for rewriting)
3. Rewriting and/or scripting
4. Rendering

Most editor routines in the extension language will operate on level 1.
Some routines will operate directly on level 2 for efficiency reasons.

> > > Finally, AFAIK, the edit tree is a concept that is local to each editor,
> > > so I not sure if you intended to make the definiton more restrictive by
> > > saying "it is just the tree which is being edited".
> > >
> > > There must be something more that I have not yet understood.
> >
> > No, the "edit tree" is shared between different views (i.e. editors).
> > Later on, we might create a second tree which contains more detailed
> > styling information, but this is not urgent; a normal style file +
> > environment variables will do for the moment.
> 
> Did you ever used different views of the same document using different 
> stylesheets? That is very useful, especially when one of the stylesheet 
> exposes otherwise invisible data. So we need that the complete transformation 
> chain as well as the object tree be local to an editor. Things could indeed 
> be optimized by using more independant abstractions of editors and views so 
> that the same rewriting would not be redone for two views displaying the same 
> document with the same transformation. 

Yes, I sometimes use this feature (although not very often).
But I agree, we need to make this feature more and more powerful.

> Force method
> ------------
> 
> We do not agree on what opaque and monolithic means.  I mean a Facade Design 
> Pattern.
> 
> Why do you insist on being able to send message to adaptaters that are 
> associated to only part of the document? Why not simply send messages to a 
> global tree rewriter with a parameter specifing the path of a notional 
> subtree rewriter?

I do not insist on this, but, in practice, it is very likely
that rewriters will reproduce very precisely the structure of
the ttrees that you are rewriting. We might even wish to
write a [] operator for rewriters, so that the two approaches would
become equivalent. But I agree that we might not want to force this,
in which case your approach is OK with me.

> I know that implementing a rewriter with an internal tree of sub-rewriters is 
> efficient (functional optimization), and that is clearly the right way to 
> implement the TMSL rewriter. But the rewriter protocol must allow any 
> implementation.

Yes, that is what I said.

> A rewriter must be a monolithic interface. It can indeed be implemented as a 
> bridge-like tree, but that must no be made mandatory. Remember: interface 
> doen not mandate a specific implementation.

OK, but remember that you probably really want to implement it as a tree.
It is very possible that you will find it handy at a certain point to
have a [] operator for rewriters. I also followed your approach
in the beginning for boxes and for widgets, but in practice,
I rapidly needed the [] operator. Also, the [] operator may be abstract...

> When we will implement the adaptater for script-based rewriters, it will be 
> time do create utility functions which perform the box to tree conversion for 
> the result of the force() method. For the TMSL, that would only be a waste of 
> cycles. Plugin rewriters could use one of the two interfaces: force gives box 
> (fast), or force gives tree (more easy to use). Anyway, plugins will need a 
> special rewriter adaptater.

Yes, that is OK too.

> So my prototype "box force(tree, path context)" is the right one, because it 
> does not mandate anything but the existence of a rewriter for the whole tree.

I am still not completely convinced.

Mainly, I do not see the purpose of the tree argument.
It is used to modify the rendering (like putting it in bold),
then I feel that this should really be done in the tree structure itself,
because we might rewrite that structure in a way that it does what you
want anyway. The tree argument is only needed as a query,
but this, in its turn, is only needed if we do not return a box,
since the box already contains all information.

Also, the path argument is not a context but a path to a subtree.

> First pass typesetting
> ----------------------
> 
> > > That explanation is needed for the reader to understand what the force
> > > method does. At least, what the force method, as I understand it, does.
> >
> > But you should not go into technical details here, because you do not yet
> > have a full understanding on what is going on here and because it does
> > not really matter here. The important thing to know is that, at the end,
> > you have a box whose physical size is known.
> 
> I am one of those people who feel comfortable when they now a bit more than 
> they strictly have to, so I assume the same for my readers. I know I have not 
> yet a full understanding of how the typesetter works, but I think the little 
> I said was correct. If it is not, I would really like the correct version.

Yes, I will give this to you, but I have no time for that right now,
so I want to concentrate on the information that you really need most.

> Ragged against justified paragraghs
> -----------------------------------
> 
> > > I used ragged text because it makes the edition much faster and much less
> > > tiring to the eye. I think you should try editing the first section while
> > > using the transformations-tags stylesheet (you will need the tags package
> > > I posted recently on the use mailing list) and justified text. But,
> > > indeed, the final document will have to be justified.
> >
> > Well, please justify it before distributing it then.
> >
> > In any case, edition of ragged text is *not* faster, although you may find
> > it more tiring for the eye (I, on the contrary, find ragged texts very
> > tiring). But it may also be a matter of using professional/normal
> > hyphenation.
> 
> Maybe, I just feel more comfortable when editing ragged text. And yes, I 
> generally use normal hyphenation.
> 
> By the way, when I say editing, I mean typing text in the middle of a 
> paragraph. I have the feeling that you never do that: you think very hard and 
> then type the quasi-final version of the text. Most people do not write 
> documents that way.

So don't I.

> Two columns
> -----------
> 
> > > I will not resist using two column format, since it is well known that
> > > multicolumned text is much easier to read: putting less strain on ocular
> > > muscles and easing considerably the practice of fast reading.
> >
> > I may agree with this for printed texts, but I do not agree in the case of
> > texts on the screen in papyrus mode, because vertical scrolling is not
> > naturally compatible with two column texts.
> >
> > Hence, please use one column text for the drafts;
> > you might switch to two column mode when printing it out,
> > using an appropriate style file.
> 
> You made a a fine point about the incompatibility of multicolumn text and 
> vertical scrolling.
> 
> I will distribute the document in A5 papyrus, since I think that A4 papyrus 
> is too wide for comfortable on-scree reading. Given the typessetting time of 
> the document, automatic page type is not an option.

That is fine. Please use 600 dpi fonts by the way.

<Joris>