Re: [Texmacs-dev] texmacs tree sanity checks needed

[PUYDT Julien]

Le lun 13/01/2003 à 14:31, address@hidden a écrit :
> On Sat, Jan 11, 2003 at 04:57:45PM +0100, Joris van der Hoeven wrote:
>  
> > > I agree a ] can go to the left; What is not normal is that this left
> > > comes on the right of the parenthesis field... That makes to lefts and
> > > no right... Which I claim is wrong.
> > 
> > I do not understand what you say here.
> 
> I think he is saying that "okay, <left|)> is useful, but it should not
> be possible (or more difficult) to have expression where <left> have
> no matching <right>".

Yes.

> One user-efficient feature would be to typeset unmatched big
> delimiters in red (and make unmatched invisible delimiters visible),
> so the user can immediately see if something is wrong without having
> to run a "structure-checker".

Yes.
 
> > > A macro... parenthesis in my opinion are used to show blocks, hence they
> > > must come by pair, to mark the begin and the end of the block. With the
> > > possibility that in some cases we don't want it to be visible (<right|.>
> > > comes to mind), but still exists.
> > 
> > Yes, so you can make a macro, which takes a block as argument and
> > puts brackets around it. You can also make a macro which takes three
> > arguments: the left parenthesis, the block, and the right parenthesis.
> 
> Actually, the macro might be an interesting solution in the abstract,
> but currently that is not really useful because:
> 
>   -- there is no way AFAIK to make the macro export properly to
>      big delimiters in LaTeX;
> 
>   -- last time I checked, expansions did not go along very well with
>      indices, superscripts, and generally the extended typesetting
>      information required to make math boxes.

Bad.

> 
> > > > > * double subscripts or superscripts (<rsub|><rsup|real><rsub|real> and
> > > > > all variants);
> > > > 
> > > > This *is* prefectly valid, but LaTeX is not able to handle it.
> > > > For instance, I sometimes whant to write f'^2.
> > > > So the user just has to be careful here.
> > > 
> > > Not sure of that:
> > > - the empty statement should get removed;
> > > - and if none is empty, they should be merged, second point.
> > 
> > That is true, but that is editing behaviour, not content correctness.
> 
> I see actually two problems here.
> 
> First, there should be a clear definition of what is "exporting to
> LaTeX". Is it trying to transmit the semantic information (then
> several superscripts of the same level are lost) or trying to transmit
> the visual layout, possibly losing some semantic information?
> Actually, I think that should be the later. That means that multiple
> superscripts on same level should be collapsed by the export filter.
> Then, maybe comments (or no-op LaTeX commands) may be used to allow
> for a reversible conversion.
> 
> The other problem is understanding the relation between editing
> behaviour and content correctness. I believe at the current point, for
> most practical purposes, this distinction is irrelevant. I may be
> meaningful for some future-TeXmacs, but at the moment it is not.
> 
> I mean TeXmacs has essentially no support for content correctness.
> Depending on the intended use, anything that the typesetter can render
> might be deemed 'technically correct content'. What we can do on the
> short term is improving the editing behaviour to make it harder to
> produce 'heuristically incorrect content'. That notion of heuristic
> correctness is often hidden in  users reports and it takes some work
> to figure out what is expected.
> 
> In that specific case, I understand that empty structures are
> generally not intended result. One way to provide expected result
> would be to remove empty structures (expansions, sub/superscripts,
> with) when the caret get out of them. I believe that fits in the
> Data Relation Definition framework.


> > > > > * double itemization: <\expand|itemize-minus><\expand|itemize-dot>;
> > > > 
> > > > This is perfectly valid.
> > > 
> > > Perfectly valid if you want to make a second list in one of the items of
> > > the first list. But when the first list has that second list as a single
> > > item, that is just bogus redundancy...
> > 
> > Still, you should be able to write such a thing.
> > But I agree that we should make that more *difficult* to do.
> 
> I disagree. At least for HTML-exporting, that is invalid code and
> should not be allowed. It might be useful as an intermediate state
> when doing some edition, but it should not be considered valid.

Can you tell me what the second list does to the output on screen and
paper? If "nothing", then it has nothing to do in the document...

> > > > > * <tabular|...> in math mode: removing it solved the problem.
> > > > 
> > > > This is also valid; it is a plainly stupid property of
> > > > LaTeX to make tabular only available in text-mode.
> > > 
> > > When the only son of the tabular is a table, same problem: bogus.
> > 
> > Here I disagree: you may want a double frame around some text.
> 
> If you want a double frame around some text then you need a table with
> a "double" border style. As a temporary work-around a macro may be
> used which internally use such a double table structure.

Agreed. And I would add: that tabular added nothing to my output... then
it had nothing to do in my document.

> Same difference: that may be meaningful to the typesetter, but that is
> not meaningful as document information.

It doesn't seem it was meaningful: I don't remember texmacs to have had
any problem when I removed them...

> That is an instance of a more general problems: some constructions may
> be meaningful for the typesetter, but do not constitute a valid
> structure. A typical example is 'expand' where the first parameter
> (macro name) is not a string node. That is meaningful for the
> typesetter and it allows some useful trick in stylesheets but it is
> not handled by export filters.

Not all valid trees for the parser are valid trees for the document.
Only the tree that is minimal among those describing well the document
should be considered valid. The others need cleaning.

> > > In that mail I proposed to eliminate <left|> and <right|>, which really
> > > look too much like a markup-like language, and replace them with a
> > > <paren||> that would be much more tree-like language, you didn't give
> > > your opinion on that...
> [...]
> > I agree that the more structural point of view can be defended.
> > One may even go further and force + to be a binary operation
> > (for instance). We will investigate all this is more detail
> > when David's rewriters will be ready. I.e. not before next year...
> 
> Yes. that is a difficult issue. Hopefully, the MathML converter will
> bring some additional insight.
> 
> 
> > But improving the editor so as to do on the fly corrections
> > that one usually expects (red -> blue -> red = noop)
> > is another matter and we can do such things before.
> 
> Maybe we need something smarter than that. The idea of "simplify on
> caret exit" (or "on save", or on mouse selection) might be more
> appropriate.
> 
> > > > Redundancy is a feature. The only thing one *can* do
> > > > is make it harder to use redundancy when you do not
> > > > really want it. For instance if you select a red color
> > > > and just after that a blue color, we might eliminate
> > > > the tag for the red color. However, if the user enters
> > > > a space in the red color, then selects the blue color,
> > > > and then removes the space, then we should keep the tag.
> 
> Why should we keep the tag? I do not understand why that may be
> desired (in this particular case). In my opinion the editor can be
> quite liberal in simplifying physical markup. On the other hand, it
> should probably be more conservative with semantic markup.

Yes, it should remove what is cruft, ie: doesn't bring anything to the
output on screen&on paper.

> > > The fact that you can embed a table in another table is a feature. The
> > > fact that you can make a table of a table (with only that) is bad.
> > 
> > As I illustrated above: no.
> > Also, when programming style files or when doing complex operations
> > on documents, it may sometimes be useful to be more permissive.
> > Make a table of a table (with only that) is usually allowed
> > in DTD's (like xhtml). One should be able to construct and edit
> > all valid texts. Nevertheless, the editor may try to make it harder
> > for you to construct seemingly (psychologically) incorrect texts.
> 
> That is almost my point when I talk of heuristically correct documents
> and of the "document subset" of the typesetting language.

I guess your "document subset" is related to that "minimal tree
representing the document" I was talking about above.

> Style files can use a wide range of tricky features which are not
> relevant to documents. Actually the definition of "style file" is not
> clear-cut since a document may contain some style definitions, but
> that is the idea.

Snark on #texmacs

PS: For the other mathematicians reading the list: this minimal tree
representing the document certainly exists, but it certainly isn't
unique in general. Finding which documents (if any) admit a unique
minimal tree is left as an exercise to the reader. ;-)