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: Patrice Dumas
Subject: Re: [help-texinfo] Changing background color of the 'verbatim' environment
Date: Sat, 15 Sep 2012 21:05:17 +0200
User-agent: Mutt/1.5.20 (2009-12-10)

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 ""dark blue"")
>       (fg ""fireengine red"")
>       (phase-of-the-moon ""one, or \"more\" (depending)"")
>       (texi:id ""the first &arobase;example example""))))
> 
> 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?

-- 
Pat



reply via email to

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