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

[Thien-Thi Nguyen]

() 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

     plistannotations

   > 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; 
(depending)&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
   else.

   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
   format?

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:

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?

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

pgpBPTgZmPHlv.pgp
Description: PGP signature