[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 1.3.5.7 (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:
>
> http://lists.gnu.org/archive/html/guile-sources/2012-11/msg00007.html
>
> 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.
--
Pat