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

[David Allouche]

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.

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


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.

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

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

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.

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.

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

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

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.

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.

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.

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.

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.

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

                                  -- David --