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

[Joris van der Hoeven]

> > I agree with you that it should rather be up to TeXmacs to
> > handle these problems, but I also want to stress that many
> > of the problem you mention are due to incorrect usage of TeXmacs.
> 
> Writing, writing, writing, then coming back to edit things, cut and
> paste various equations, etc... Are an incorrect usage of TeXmacs!?

No, but at the moment, you should for instance be aware of the fact
that, inside red text, selecting blue and then red again is not a noop.

> > > errors I found in my texmacs document:
> > > * <left|)> instead of <right|)> ;
> > 
> > This is a typical error which is due to *you*.
> > For interval notation, many people use left ], for instance.
> 
> 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.

> > > * <left|{> unmatched by a <right|.> ;
> > 
> > You can create a macro for this. But the problem with
> > this approach is that you also loose flexibility when typing.
> > Nevertheless, I plan to come with some other approaches
> > for this problem later. But that will not be soon.
> 
> 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.

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

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

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

> Here came the little list of problems, classified by type:
> 
> > > A I see it, these problems can be classified in two types:
> > > - <left|*> and <right|*> are by their very nature (look at the names!)
> > > supposed to come in pairs;
> > 
> > You can create a macro "matching-bracket"
> > in order to solve this problem.
> 
> 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...

This is indeed a possibility which we will investigate in the future.
But this introduces a lot of additional rigidity too,
not to speak about difficulties from the editing point of view.
For instance, how to represent middle delimiters?
How to easily remove a parenthesis and replace it by another one?

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

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.

> > > - redundancy isn't eliminated.
> > 
> > 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.
> 
> 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.

> > > - perhaps having a clean-tree function, that would be called when the
> > > user has edited a part of the document, and would spot and remove:
> > >   * empty statements like <subp|> and the like;
> > >   * double statement without meaning like a table whose _only_ member
> > > would be another table?
> > 
> > That is also a good idea, which I indeed intend to implement
> > once when I have time. One may also see this as some kind
> > of "structure checking" (like "spell checking").
> 
> It is not only checking, it is fixing, too.

Of course, that is what I mean ; a spell checker does that too.