[Top][All Lists]

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

Re: A replacement for Info

From: Patrice Dumas
Subject: Re: A replacement for Info
Date: Thu, 29 Nov 2012 20:33:29 +0100
User-agent: Mutt/1.5.20 (2009-12-10)

On Thu, Nov 29, 2012 at 07:08:28PM +0100, Thien-Thi Nguyen wrote:
> () Patrice Dumas <address@hidden>
> () Wed, 15 Aug 2012 00:04:47 +0200
>    > This points to another subtlety of texinfo: IIUC the lifetime of a
>    > variable or setting (or macro) is indefinite.  That is, if you
>    > address@hidden a variable in (a subsubsection in the first
>    > chapter), that value will hold for all subsequent nodes (even 2.1,
>    > i.e., higher level), until EOF or another address@hidden changes it.  
> This
>    > means we need to record where such settings are done to know their
>    > "span of influence".
>    It is worse than that.  User defined macros and @value expansion may
>    happen out of a balanced tree.  So these 2 constructs are expanded
>    when constructing a proper tree in texi2any.  It should be possible
>    to keep a 'mark' where they appeared (it is on the TODO list), but
>    they cannot be kept in the tree like the other commands are, since
>    the tree would not be a tree anymore.  If a generated sexpr tree is
>    generated through makeinfo/texi2any, my idea is that the tree would
>    have user defined macros and @value already expanded (macros
>    definitions and @set would be in the tree, though).
> I'm reviving this thread to point out some EXPERIMENTAL code that
> hackers (familiar w/ Guile) might find useful for trying out ideas.
> Here's the announcement to the guile-sources list:
> Unfortunately IXIN 1.0 does not propose any solution to the "scope
> dishonoring" nature of texinfo (c.f. "it's worse than that" above).
> Maybe there's a way to specify that info either in the ‘meta’ section
> (which already contains a good bit of "global" settings) or along w/
> each entry in the ‘index’ section.  Hmmm.  Any thoughts?

I think that it is too soon to answer that (at least for me ;-).  Maybe
it is hopeless and  we should propose something completly new.  I don't
want to speak in his place, but I think that it is more or less what
Karl advocates.  Considering that we keep it, I still havent found a 
way to place this information nicely.  Once it is there, I think that 
additional information that wouldn't be in the XML would deserve a 
distinct section in the IXIN file.


reply via email to

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