[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
- Re: "special" spaces in Texinfo parsing and output, Patrice Dumas, 2013/08/04
- Re: "special" spaces in Texinfo parsing and output, Karl Berry, 2013/08/04
- Re: "special" spaces in Texinfo parsing and output, Patrice Dumas, 2013/08/05
- Re: "special" spaces in Texinfo parsing and output, Karl Berry, 2013/08/05
- Re: "special" spaces in Texinfo parsing and output,
Patrice Dumas <=
- Re: "special" spaces in Texinfo parsing and output, Patrice Dumas, 2013/08/05
- Re: "special" spaces in Texinfo parsing and output, Karl Berry, 2013/08/05
- Re: "special" spaces in Texinfo parsing and output, Patrice Dumas, 2013/08/06
- Re: "special" spaces in Texinfo parsing and output, Patrice Dumas, 2013/08/07
- Re: "special" spaces in Texinfo parsing and output, Karl Berry, 2013/08/08
- Re: "special" spaces in Texinfo parsing and output, Patrice Dumas, 2013/08/09
- Re: "special" spaces in Texinfo parsing and output, Karl Berry, 2013/08/09
- Re: "special" spaces in Texinfo parsing and output, Dumas Patrice, 2013/08/10
- Re: "special" spaces in Texinfo parsing and output, Karl Berry, 2013/08/11
- Re: "special" spaces in Texinfo parsing and output, Dumas Patrice, 2013/08/12