gnu-system-discuss
[Top][All Lists]
Advanced

[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: Wed, 15 Aug 2012 00:04:47 +0200
User-agent: Mutt/1.5.20 (2009-12-10)

On Tue, Aug 14, 2012 at 10:35:14PM +0200, Thien-Thi Nguyen wrote:
> 
> between the source and target vertices.  A better explanation is at:
> 
>  (info "(elisp) Circular Objects")

Ok.

> That said, we want to be nice to programs that have only basic ‘read’
> capabilities, and should plan to support references "manually".  (That's
> what INDEX is for -- to support on-demand dereference, sidestepping the
> requirement that everything be held in memory.)  So the full answer to
> your question is "yes, but doing so would be bad design (IMVHO, YMMV)".

I think it really depends on what is to be represented.  To represent
the link between an @author command and the associated @quotation, I
don't think an index should be used, but instead such kind of reference
could be ued.  But for index commands and printindex, floats and 
listoffloats, sure they belong to a special INDEX part.  But I don't
really mind in fact, just tell me what you want, I'll construct it.

>    As for the information that may be wanted in a renderer, looking at
>    what is available now, there is the index informations (index
>    entries, merged indices), informations on floats (for @listoffloats),
>    informations on labels (@node, @anchor, @float with label) especially
>    for internal @*ref, a possibility to access the tree of some
>    @-commands, like @copying, @documentdescription, @top, @settitle...,
>    and some misc informations, like the succession of @direntry and
>    @dircategory, the input file name.
> 
> We mustn't forget the all-important address@hidden [froth froth] !!!
> I have been waiting a long time for that to be runtime-tweakable...

That is to be found in the tree, as it affects all the Texinfo coming
after the @-command.  Some @-command affect the whole document, so would
be available right at the beginning of the rendering.

> 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).

-- 
Pat



reply via email to

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