[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: Thu, 29 Nov 2012 04:17:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

() Patrice Dumas <address@hidden>
() Sat, 15 Sep 2012 21:05:17 +0200

   On Thu, Sep 13, 2012 at 11:25:09PM +0200, Thien-Thi Nguyen wrote:

   > Exactly; a separate (very simple) parser for reading a plist is
   > needed.  Attributes are stuff that makeinfo acknowledges exists,
   > checks for syntax errors, but doesn't otherwise further act upon
   > (except for a few special cases).

   It should not even check that there are syntax errors or not, except
   if doing a format that really uses what is passed, that is, in a
   downstream processing.

   >    I think that this should better be put in raw formatting.  If
   >    this is for processor of format foo, it is possible to add
   >    anything with (but notice that @ has to be escaped)
   >    @inlieraw{foo, bg "dark blue"  fg "fireengine red"
   >                    phase-of-the-moon
   >                    "one, or \"more\" (depending)"
   >                 texi:id "the first @@example example"}
   > It is not for format foo specifically, it is just general style
   > info, or even notations.  Whether or not the author succeeds in
   > communicating w/ particular processor foo is not a concern for
   > makeinfo.

   foo do not need to ba a true format.  It could be a 'pseudo-format'
   that allows to flag annotations, for example it could be


   > Translated to SXML:
   > (inlineraw
   >   (inlinerawformat "foo")
   >   (inlinerawcontent
   >    (@ (spaces " ")
   >       (bg "&quot;dark blue&quot;")
   >       (fg "&quot;fireengine red&quot;")
   >       (phase-of-the-moon "&quot;one, or \&quot;more\&quot; 
   >       (texi:id "&quot;the first &arobase;example example&quot;"))))
   > which would be fine, if it were attached to ‘example’, not specific
   > to any format, and strings interpreted as in C:

   Strings should be interpreted by the downstream processor.  For
   makeinfo it is just some plain text that is passed down appropriately
   quoted depending on the output format, so here I think it should be
   up to the dowstream processor to transform this XML to something

   Now, the association with the previous or next element/command, that,
   indeed, may be of use for the processor.  On that subject, I don't
   have a clear idea of what could be done by makeinfo to help a
   processor associate an information, which may be in @inlineraw, for
   example, or somewhere else, to the next (or previous, or parent)
   Texinfo construct.

   The simplest, from the makeinfo point of view, would be not to do
   anything, and the downstream processor would determine the
   association based on the tree (in whatever format this tree is used
   by the downstream processor, XML, s-exps tree, internal perl
   tree...).  Should there be something more done, and if so in which

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.)  If you get a chance, please see:

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?

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: pgpBPTgZmPHlv.pgp
Description: PGP signature

reply via email to

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