Re: [help-texinfo] Changing background color of the 'verbatim' environment

[Thien-Thi Nguyen]

() Patrice Dumas <address@hidden>
() Tue, 11 Dec 2012 23:49:53 +0100

   As a general remark, indices need not be 2 letter, even though it is 
   recommended to use 2 letter names.

OK.  I was looking for a short name.  How about TX for "term index"?

   >    To be able to format a printindex rapidly, the index entries
   >    should be easy to access directly, so, in my opinion all should
   >    be in the file (duplicated) with the beginnning and end offsets
   >    just like nodes.
   > 
   > IXIN 1.3 is available: <http://www.gnuvola.org/software/ixin/>.  It has
   > section tree and two-letter indices (NB: non-duplicated), but not tweaks

   Indeed, if the node is in main text, no need to duplicate.  Yet, if I
   have read correctly, in the

   *** tli (zero or more)

   you duplicate the index entries in TERM, although it could also be an
   offset and a length.  Not really a big deal.

Yes, the TERMs are duplicated but not triplicated (as in: they do not
appear in the node where ‘printindex’ resides, which is what i
understood you to be requesting, previously).  Providing offset/length
would require the rendering program to grovel through node data, which
is opposite of what we want.

   >     - META-divvying work-in-progress
   >   
   >         See new header "groupings" in README.

   Looks good.  

Thanks for reviewing.

   codequotebacktick codequoteundirected txideftypefnnl have a non set 
   form, and it should be that way, using @set in place of commands
   is not what we do today.

So, texi2any will silently replace address@hidden txiFOO’ with ‘<FOO 
value="on">’
and likewise address@hidden for these three vars?  That would be ideal from
the rendering program pov, as long as the behavior is documented.

   Regarding your interrogation about @documentencoding,
   @documentencoding indeed should in general be unique.  However,
   texi2any should behave correctly if another part of the document has
   a different documentencoding.  I guess that TeX may be less
   forgiving.  In any case, I think that IXIN should only try to handle
   files utf8 encoded, whatever the documentencoding (or use the ***
   coding you propose) and so should not really do anything upon
   encountering.

OK.  It will be noted, just like the others.

   documentlanguage should certainly also be in the XID, to have a 
   language to start with, as it may be needed even before the meta 
   section, for instance for title, title page, copying....

OK.

   > I wonder if there is a better term than "section tree".  

   The manual uses "chapter structuring".

That's not entirely satisfying, either.  The things we structure include
chapters, but not only.  Hmmm.

   > Another, more important, doubt is how to make sure that functions
   > in the ‘cp’ index (say) are formatted with address@hidden as opposed to
   > address@hidden  That information doesn't seem to be captured anywhere.

   That's indeed an interesting information that should be added,
   especially since it is not necessarily easy to find out because of
   merged indices entries.  Also the index the entry is finally
   associated with, if there are indices merged with @syn*index.

Here's an idea (thinking aloud).  Change TX from:

 (TERM NI...)
 ...

to

 (FACE EXCEPTION)
 (TERM NI...)
 ...

where FACE is ‘tt’ or ‘r’ and EXCEPTION is a N-bit integer, with N the
number of entries in the TX.  (If there are no exceptions, this is 0.)
So ‘fn’ would look like:

 (tt 0)
 ("access" 1)
 ("quit" 2)

and a mixed ‘fn’ into ‘cp’ (via address@hidden fn cp’) like:

 (r 5)
 ("access" 1)            ; entry 0 => 0x1
 ("around, fooling" 1)   ;       1 => 0x2
 ("quit" 2)              ;       2 => 0x4

Here, 5 encodes the intent that entry 0 and entry 2 should be in ‘tt’.
Of course, this requires rendering programs to handle high N, but that's
not so onerous (and usually N is (lamentably) not that high, anyway).

   You still miss something similar with TLI handling for listoffloats /
   floats.

Yes, thanks for the reminder.  Where can i find a representative .xml
(or .texi processible by makeinfo 4.13) for testing?

   Regarding macro, I think you don't need them.  They should be fully
   expanded (as well as @value) in the IXIN document.

Good.

   Last, about xml to sxml using the perl module, I'll have a look.

I tried to muster courage but my Perl experience is 20-years rusted...

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

pgpTa84izvzIf.pgp
Description: PGP signature