Re: transforming texinfo sources

[Patrice Dumas]

On Fri, Dec 09, 2011 at 04:01:54PM -0800, Karl Berry wrote:
>     PS: irrespective of what is decided, I think that adding elements in the 
> tree
>     when entering or leaving an @include file, which would be ignored by all 
>     the output formats is an interesting idea.
> 
> I agree that is often useful information.  The information could be
> propagated into the HTML/XML/Docbook output as comments.

I was thinking that this kind of information deserved a specific
tree element type (alongside with commands, containers and text), 
I was about to call the associated key 'invisible' but it isn't 
very bright. Maybe 'hidden', or 'underlying'? I think it could 
also be used for @ protecting end of lines in @def* lines, beginning 
and end of user defined macros, beginning and end of value expansion.

So, for example an @include will be in the tree something like

{'underlying' => 'include_begin',
 'extra' => {'filename' => 'filename.texi'}},

....

{'underlying' => 'include_end',
 'extra' => {'filename' => 'filename.texi'}}

>     only when the user defined @-macros do not break the tree structure
>     of the Texinfo document.  But I think this could be useful sometime.
> 
> I agree that @macro's which mess up the node structure are
> rare/nonexistent.

It is not the only pre-requisite, to be able to get a tree, it
also has to keep more generally the document tree structure,
not only the node structure.

A rather artificial but problematic construct would be
something along

@macro close-brace {}
}
@end macro

@code{in address@hidden

Since the tree would have everything in the @code.

>     Is it worth toying with that idea?
> 
> Sure, except for the sake of getting the release out :).

I don't do anything more for the release, this is a post-release
activity...

> I'm not quite following all the details of your proposal, but that's ok.
> The auto-addition of nodes and menus sounds interesting.  Especially if
> the Emacs people would actually like to cooperate for a change and make
> use of the feature instead of reimplementing it.  Maybe you'd like to
> write them (address@hidden) to see if they're at all receptive to
> the idea?

Ok, I'll do.

-- 
Pat