[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [help-texinfo] Changing background color of the 'verbatim' environme
From: |
Thien-Thi Nguyen |
Subject: |
Re: [help-texinfo] Changing background color of the 'verbatim' environment |
Date: |
Mon, 03 Dec 2012 18:32:42 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) |
() 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
- Re: [help-texinfo] Changing background color of the 'verbatim' environment,
Thien-Thi Nguyen <=
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Patrice Dumas, 2012/12/04
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Thien-Thi Nguyen, 2012/12/11
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Karl Berry, 2012/12/11
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Patrice Dumas, 2012/12/11
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Thien-Thi Nguyen, 2012/12/11
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Karl Berry, 2012/12/12
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Thien-Thi Nguyen, 2012/12/13
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Patrice Dumas, 2012/12/11
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Thien-Thi Nguyen, 2012/12/12
- Re: [help-texinfo] Changing background color of the 'verbatim' environment, Thien-Thi Nguyen, 2012/12/12