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

[PUYDT Julien]

Le lun 06/01/2003 à 19:35, Joris van der Hoeven a écrit :
> > I looked at the texmacs' sources conversion functions (in totex.cc and
> > tmtex.scm), but couldn't find the problem; I then compared the .tm and
> > .tex where the first error was: the error didn't appear in the
> > conversion, it was there in the texmacs file! Hence I consider the
> > texmacs file was corrupt, even if texmacs has no problem to handle those
> > problems.
> 
> 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!?

> > I did clean (de-corrupt) the texmacs file by hand (ie: I made it a valid
> > texmacs file that gave a valid latex file), and here is a list of all
> > 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.

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

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

> > * a '(' matched by a <right|)> (or the contrary);
> 
> Similar to ^^^.

I know, I make a shorter list later. I was just giving the list of
problems I encountered while cleaning, in the order I found them...

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

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

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


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

When you really work on a text, you write, come back, edit, cut, paste,
re-edit, etc... The tree structure is then bound to become unclean in
some way or another. Unless there is some function that cleans.

As I said, I'll do my best to provide patches if I find the time and if
I understand the code in question...

Snark on #texmacs