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

[Thien-Thi Nguyen]

() Patrice Dumas <address@hidden>
() Thu, 13 Sep 2012 15:08:54 +0200

   This is already possible to do something similar with what you
   propose by using raw formatting.  Something like

   @macro redbackground{something}
   @html
   <div class="redbackground">
   @end html
   \something\
   @html
   </div>
   @end html
   @end macro

   and supply the correct CSS information through one of the way to
   provide css information.  But this only works if the format handles
   some customization which doesn't seems to be the case for TeX.

This doesn't work for any other renderer that might have a concept of
"background color" that doesn't recognize ‘<div class=...>’.  Also, w/
this construction, the attribute is not attached to a semantically
useful unit (such as environment or node), which i suppose is okay for
HTML/CSS.  Plus, it's prone to user error (mismatching <div> or improper
nesting), etc...

After some thought, i think the association between a set of attributes
and some semantic unit is the most important part of the suggestion.
The fine syntax is, of course, debatable... :-D

   That looks like a new layer above Texinfo which doesn't look like
   Texinfo at all.

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

   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.

   > Yeah, i know this is getting ugly real fast, but figure (sometimes) some
   > beauty can be achieved by confining ugly and ignoring it.

   Those inlineraw constructs will be in the internal tree, but will
   be ignored by all formatters except for a formatter that explicitly 
   handles this format (or pseudo format) and it will appear in the 
   Texinfo XML as:

   <inlineraw><inlinerawformat>foo</inlinerawformat><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;</inlinerawcontent></inlineraw>

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:

(example
 (@ (bg "dark blue")
    (fg "fireengine red")
    (phase-of-the-moon "one, or \"more\" (depending)")
    (texi:id "the first @example example"))
 "...")

This is very similar to the input, unsurprisingly.

   I don't think we need to add more specific things to the language (we
   already have enough inconsistencies with menus, @def*, @macro....).

Ah well, in that case, never mind.  I imagined myself in your (and
Karl Berry's) shoes, but i guess my feet were pointed in the wrong
direction.  :-D

   Now if we have some argument we think are usefull for a whole class
   of output, we can add it to @example.  For example, we could have

   @example C, red
   some C code
   @end example

   with C the language of the example and red the background.  But I am
   not sure we need that.

I am quite sure that makeinfo doesn't need it (it hasn't, so far), that
anyway someone would like to specify it, and that anyway some downstream
program would be able to do a decent job of rendering it prettily.  If
makeinfo can connect these parties w/o undue interference, that's a win.
-- 
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 ...........

pgpWSx0KH9451.pgp
Description: PGP signature