help-texinfo
[Top][All Lists]
Advanced

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

Attachment: pgphdtJwxKTPO.pgp
Description: PGP signature


reply via email to

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