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

[david]

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

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

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


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


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

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

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.


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

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

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.

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.