[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:59:15 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) |
() Patrice Dumas <address@hidden>
() Sat, 1 Dec 2012 09:27:20 +0100
Afer ore thinking, and answering to myself, I think that the most
efficient would certainly be to have the value at the end of the
preamble for those commands in the META section, because, in most
cases this is not changed in the document, and add in the index the
state at the beginning of the node only if it differs from the
value at the end of the preamble.
Hmmm, if i understand correctly, you want to maintain VARS and SETTINGS
in META, but modify INDEX entries to go from:
(NAME LENGTH NEXT PREV UP)
to:
(NAME LENGTH NEXT PREV UP [TWEAKS...])
where each TWEAK could override some element in VARS or SETTINGS. In
this case, there need not be any TWEAKs list at file top-level. Does
that sound right? I think that would work, too.
> Is the point having everything in only one file?
After thinking a bit about it, indeed having everything in one file
would be practical.
Yes.
But I can't see what a base64-encoding and gzipped representation
adds. A plain SXML text representation should certainly be better,
with beginning and end of node indexes. For figures, base64-encoded
gzipped would make sense, though.
Unfortunately, plain text is easier to corrupt undetectably. Too,
piping plain text around requires everyone to take pains about encoding
issues on the outside of their program as well as on the inside (which
is hard enough, look at all the kludges/bugfixes succumbed by a2ixin!).
Actually, a2ixin is not a good example -- its role is to mimic some
future makeinfo, which we KNOW will DTRT :-D, rather than a renderer.
Compression is good, generally, anyway. On the other hand, base64
indeed is superfluous. I think i added that mostly for aesthetics.
(But then again, it does help keep text encoding issues "internal".)
--
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 ...........
pgphdtJwxKTPO.pgp
Description: PGP signature