Re: "special" spaces in Texinfo parsing and output

[Patrice Dumas]

On Sun, Aug 04, 2013 at 09:47:58PM +0000, Karl Berry wrote:
>     So the only thing I need to add to the parser is detecting ^L within
>     paragraphs and have it stop and restart a paragraph.  
> 
> Thanks.
> 
>     I am still unsure whether I should add an end of line to the
>     paragraph being closed, I guess not.
> 
> What's the difference?

The tree is not the same as the output.  I don't think that in the tree
I should add a new line, but in the output it may be better.  For
instance, if the text is

  Text ^L other

the tree wouldn't have a newline added:

{'paragraph' => {'content' => [
   { 'text' => 'Text '}
 ]}
{'text' => '^L', 'type' => 'empty_line'}
{'paragraph' => {'content' => [
   { 'text' => ' other'}
 ]}

(A bit more complex in reality, but the point is no additional newline
or other character).  Then in the output it should be as you say, at least 
in Info, with added newline.


Handling the form-feed is more complicated than what I thought.  Here is
where I am now, in terms of design:

* form-feed in paragraph stops a paragraph and starts another but only
  if not nested in a @-command.  For instance in the following, no 
  paragraph stopping and restart, as it is in @code:

    Something @code{AA ^L BB} other

* form-feed is treated as a regular space in all line-oriented
  @-commands, @center, @exdent, @node, @section, @ifclear, @end, 
  @columnfraction, @clickstyle, @definfoenclose, @alias, @synindex...
  also in menu.  Also on @macro definiton first line.  Also on # 
  m4 directive lines.  Also on lines at the very beginning of the
  document.  Therefore it will be in the tree, and will be either
  ignored if in ignorable spaces, or passed as-is in text fragments
  in those cases.

* form-feed is kept as is in preformatted contexts, @example...

-- 
Pat