texinfo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spec for @inlinehtml etc.


From: Patrice Dumas
Subject: Re: spec for @inlinehtml etc.
Date: Tue, 27 Dec 2011 23:43:57 +0100
User-agent: Mutt/1.4.2.2i

On Mon, Dec 26, 2011 at 03:58:39PM -0800, Karl Berry wrote:
> Hi Patrice,
> 
>     If I am not wrong this would mean that the main difference with
>     normal Texinfo code would be that text would be raw text, that is,
>     no escaping of special characters.
> 
> It's true that one of the original ideas of the raw blocks was to allow
> use of bare { and } without causing errors.  Important for TeX, although
> braces are not a big part of html|xml|docbook.

They are part of html, if one want to output some javascript.  And I do
believe that this is one possible use of @html blocks, that is generate
specific code with javascript or weirdest things.  similarly, there is CSS,
and I think there are a lot of weird stuff in CSS, although there are 
many way to deal cleanly with CSS in makeinfo already.

But that was not my point.  My point was the trivial idea that something 
like <br/> does not becomes &lt;br/&gt;.

>     certainly be to consider those blocks as preformatted (as if in
>     @example and similar) and in addition mark text with type 'raw'.
> 
> Thus making the output not be typewriter by default?  (Which should
> surely be the case for raw blocks.)

I don't really get your remark...  The issue here is more how the Parser 
parses the Texinfo code, not how it is rendered.  Both are not completly
independent, sure, but not completly tied either.  As far as outputting is
concerned, it is likely that the current code will be able to process
the resulting tree without much change (in HTML, preformatted are meant to
be in <pre>, this would not be the case for @html blocks, for example).

> I think there should be no automatic paragraph generation.
> 
> If the user wants a <p>, they should put it in themselves.  That's what
> raw mode is all about.

Ok.  That will be automatically done if in 'preformatted'.

>     I think it is better to do the right thing for such an important issue
>     even if it delays a bit the release.
> 
> Yes.  Though I find myself puzzled as to the best thing to do.  The
> current behavior of tp is completely consistent and logical, in its way.
> But since it is so far from the behavior of @tex, I'm not sure it's best
> for users.  On the third hand, I'm not sure if there's any real use of
> the raw blocks except for @tex.  I don't recall ever coming across them.

I have seen uses of @html to produce specific fragments of html when
not being satisfied by the default.

> My hunch is that the most useful Texinfo commands in raw blocks are the
> simple character-producing commands, like @@ -- the "insertions within a
> paragraph" section of the refcard, to a first approximation.  Exception:
> @math{} seems fraught with problems with me.

In my opinion, @math and maybe @clicksequence should not be in that 
section, but that's a disgression...

> The simple markup commands ("marking words and phrases" in the refcard)
> also seem viable, except for @verb, which is nonsensical in raw
> contexts.
> 
> @errormsg, @c(omment), why not.
> 
> Cross-references ... hmm.  It seems harmless enough to allow them,
> though probably not useful.
> 
> Wdyt?  Perhaps we should ask for input on bug-texinfo, at least if
> anyone has ever used @html, etc.

Indeed, that is certainly a subject for which users may have preferences.

In the mean time, I will implement 
@atchar{} @lbracechar{} @rbracechar{} @backslashchar{}.

-- 
Pat



reply via email to

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