texinfo-devel
[Top][All Lists]
Advanced

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

Re: "special" spaces in Texinfo parsing and output


From: Patrice Dumas
Subject: Re: "special" spaces in Texinfo parsing and output
Date: Tue, 6 Aug 2013 01:14:26 +0200
User-agent: Mutt/1.5.20 (2009-12-10)

On Mon, Aug 05, 2013 at 09:27:03PM +0000, Karl Berry wrote:
>     no paragraph stopping and restart, as it is in @code:
>         Something @code{AA ^L BB} other
> 
> In TeX, it does start a new paragraph there.  Just like it was
> @code{AA
> 
> BB}
> That seems to be logical?

That's not possible to do that in texi2any: it would break the tree 
structure.  So it is not that logical...

I tested that you're right, a ^L does start a paragraph within a
@code with TeX.  However, Tex do not accept something like
 
 @code{AA
 
 BB}

but complains with:

Runaway argument?
{AA 
./test_ff.texi:9: Paragraph ended before @codex was complete.
<to be read again> 
                   @par 
l.9 

And texi2any also isn't happy with an empty line in @code and says:
k.texi:2: @code missing close brace
k.texi:4: misplaced }


Back to ^L nested in @-commands.  Do you really want something different
from ^L being considered as a regular space by the Parser?  The ^L is
not necessarily lost to the converters, they may still do something with
that character, but my opinion is that that it should stop and start a
paragraph. 




Another point, if there is something like 

address@hidden ^L in footnote}

currently (once I commit) texi2any do not consider ^L as stopping and
starting a paragraph, as there is no paragraph to start or stop, but
rather put it in a 'text' with 'type' = 'empty_spaces_before_argument'.
Same for @email, for instance.

Similar with a lone ^L appearing on a line by itself (goes in
'empty_line'), or at the beginning of a paragraph before any text (goes
in empty_spaces_before_paragraph).

It is possible to output those ^L in converters, then, but it is not
really practical as in normal converters, those kind of containers
(except for empty_line, in general) are simply ignored (it is the case
for both of empty_spaces_before_paragraph and
empty_spaces_before_argument).

I think that it is better not to d an empty paragraph in those cases, 
but should the spaces with ^L that ends up in ignorable space text 
container be tagged especially?

-- 
Pat



reply via email to

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