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

[Thien-Thi Nguyen]

() Patrice Dumas <address@hidden>
() Thu, 29 Nov 2012 13:22:52 +0100

   > Since this last exchange a couple months ago, i've tried to answer "in
   > which format" by playing w/ code.  (I agree that makeinfo should be
   > hands-off, for the most part, btw.)

   I had the opposite idea.  To me, the idea was that makeinfo would
   generate both the XML that describe the nodes, and the IXIN file
   that describes the whole document.

Sorry, i was imprecise.  We have basically the same idea, that makeinfo
be the authoritative source for some "to be defined as we go along" file
format.

   All the code is already there, since makeinfo basically has in memory
   all this information to be able to do the HTML output.  If you want
   to have the code as lisp, sure it won't be convenient, but doing it
   in makeinfo/texi2any should be very simple, using the XML backend for
   the nodes, and the code used for HTML for the indices as it is very
   similar.

IXIN proposes one format, and includes tools for writing and reading it,
but those are just to play around, to inform the file format design.
The end product of this exercise is primarily the format spec and not
the toy tools.  How non-toy programs are implemented to read (but not
write, since that is makeinfo's purview) such files is not important.

   > http://www.gnuvola.org/software/ixin/
   >
   > I think the priority is to define the "container shape", which is
   > what IXIN 1.0 aims to do; precise design / interpretation of the
   > (S)XML-ish contents can be done later.  What do you think?

   A agree, although I think that using the texinfo XML would be the
   correct thing to do: if it is not suitable, that would certainly show
   that it has to be modified.

It seems the (S)XML alone is not sufficient.

IXIN 1.0 and 1.1 only modified the (S)XML a little, by dstructively
extracting ‘nodename’ and the link elements node{next,prev,up}, as
leaving them in each ‘node’ is redundant.  These releases left ‘meta’
more or less undisturbed.

IXIN 1.2 turns further away from (S)XML in ‘meta’, which now looks like:

 (ATTRS XID VARS SETTINGS COPYING TITLEPAGE ELEMENT...)

In particular, XID, VARS, and SETTINGS are not (S)XML, but in a format
less-tediously accessible (simple lists, and association lists).  These
are described in the README.

   Some remarks:

   * sectionning tree.  I think that, in addition to the node tree, the
     sectionning tree (@part, @chapter, @section, @unnumbered...) should be
     present and index the corresponding nodes too.

Is there a strict 1:1 correspondance between elements of the sectioning
tree and elements of the node tree?  Can a section have zero or multiple
nodes?  Can a node have zero or multiple sections?

Presently, in META, the last element is usually ‘(contents (@))’.  How
about replacing that element w/ the sectioning tree?  Another idea is to
place it after the index, so that the file format looks like:

 MAGIC
 META
 COUNTS
 INDEX
 S-TREE
 NODES

Maybe that would be more straightforward, since S-TREE can refer to the
node indices (0 for "Top", etc), then.

   * the meta part is not completly clear to me.  Is the idea to have a
     container for information set for the whole document:

             'documentdescription',
           'evenfootingmarks', 'evenheadingmarks',
           'everyfootingmarks', 'everyheadingmarks',
           'fonttextsize', 'footnotestyle', 'novalidate',
           'oddfootingmarks','oddheadingmarks',
           'pagesizes', 'setchapternewpage',
           'setcontentsaftertitlepage',
           'setfilename',
           'setshortcontentsaftertitlepage',

     or something else?

Some of these are in XID,  The rest could go in SETTINGS.

   * if you want 'random' access to nodes, you need to also give some
     information on the document state at the beginning of the node.
     Roughly, this corresponds to

          'allowcodebreaks', 'clickstyle', 'codequotebacktick',
           'codequoteundirected', 'deftypefnnewline',
           'documentencoding', 'documentlanguage', 'exampleindent',
           'firstparagraphindent', 'frenchspacing', 'headings',
           'kbdinputstyle', 'paragraphindent',
           'urefbreakstyle', 'xrefautomaticsectiontitle',

These could go in SETTINGS, too.

     And the processor should be able to process an information of a
     change in those.  Some may not be needed, in fact if the
     information is already in the XML (for instance, I think clickstyle
     is also in an attribute of @click or something like that).

Hmm, i suppose there should be another place to specify nodes that
modify settings.  The processor must accumulate these.  Something like:

 ...
 INDEX
 S-TREE
 (TWEAK...)
 NODES

where TWEAK is ‘(INDEX (NAME VALUE)...)’.  In this case, we could
actually move (some of the) SETTINGS out of META and into the list of
TWEAKs, as the first one: ‘(0 (NAME VALUE)...)’.  If "Top" has its own
tweaks, those would have to be merged -- no big deal (i think).

   * index of indices entries.  At least the node containing the indices
     entries (@cindex...) should be indexed somewhere, to be able to
     format a printindex.

Agreed -- see TLI in COUNTS.  E.g., hello.ixin says ‘((cp 6))’.  Or am i
misunderstanding something?

     I that that it would be even better to have
     an XML representation of the index entry text.

Yes.  That info should lie in the node, i'd think.

   A last remark, using a base64-encoded gzipped nodes representation
   seems weird to me, why not simply an xml file per node with a file
   name constructed similarly as for html, with additional care for
   avoiding to have different nodes in the same file?  Is the point
   having everything in only one file?

   For the index entries, maybe the base64 stuff would be useful for
   rapid direct access.

I see you revisited these thoughts in other posts; i will do likewise.

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

pgpnochb1bABe.pgp
Description: PGP signature