texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Re: [bug]: Bad carriage return handling while parsing .tm


From: David Allouche
Subject: [Texmacs-dev] Re: [bug]: Bad carriage return handling while parsing .tm files
Date: Fri, 27 Sep 2002 10:47:31 +0200
User-agent: Mutt/1.4i

Nicolas sent us an interesting bug report some time ago. Since the
reply contains information of general interest to TeXmacs developpers
I decided to post it here, instead of going on privately.

On Thu, Aug 01, 2002 at 12:14:10AM +0200, Nicolas Girard wrote:
> Severity:
>   low
> 
> Description:
>   Bad carriage return handling while parsing .tm files
> 
>   The parser handles correctly the following document:
> 
>   <\body>
>   <expand|tabular*|<tformat|\
>     <table|\
>       <row|\
[snip]
>         <cell|CC>>>
>   >>
>   </body>
> 
>   However, this document causes a crash:
> 
>   <\body>
>   <expand|tabular*|<tformat|\
>     <table|\
[snip]
>     >
>   >>
>   </body>
> 
> 
> Note:
> This works well if all lines inside the body end with a backslash.
> So maybe this is what the parser expects. But this seems unnecessary,
> the more so as without the need to write backslashes style files would
> be easier to read and to develop

First of oll, apologies for the late reply.

That may not be considered a bug. Here are some of the rules (non
authoritative, I have not read the source) followed by the TM parser:

  -- A single newline is considered whitespace.

  -- Successive, non-escaped witespaces are collapsed to a single whitespace.

  -- In <env|param1>, is called an inline parameter.
     In <\env>param2</env> is called a block parameter.

  -- If an inline parameter of X contains only one element Y, the node
     Y is used as an immediate child node of X.

  -- If an inline parameter of X contains several elements Y..Z, the
     nodes Y..Z are used as children of an implicit CONCAT node which
     is used as child of X.

Obviously TFORMAT expect it last subtree to be a TABLE, but in your
second example the last subtree of TFORMAT is something like:

    (concat (table ...) " ")

So this is not really a problem with the parser. It may be considered
to be a problem with the typesetter not being safe enough, but that is
a design choice to avoid losing performance by being anal on input
integrity.

Rather, I consider that to be a deeper problem with the document
format not being well defined. On the short term, that is unlikely to
change. On the longer term, the use of validated XML may partially fix
this. But the introduction of the new stylesheet system is probably
going to introduce whole new classes of related weaknesses.

Joris, maybe we should keep that in mind, and find ways to make it
harder to crash the typesetter when we will implement the rewriting
system?

-- 
_.      _    .   GNU TeXmacs -- Writing is a pleasure.
 |\     |    |\       Home page -- http://www.texmacs.org
 | \ ,-.|,--.| \      Resources -- http://alqua.com/tmresources
 |  \|  |,-+||--\            TeXmacs is NOT a LaTeX front-end
-+--'`- \`-'\-   -           and is unrelated to emacs.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]