Re: spec for @inlinehtml etc.

[Karl Berry]

    > Having a delimiter character like @verb turned out to be rather a lot of
    > extra complication, and I didn't see that it gained anything in 
particular.
    It was exactly for the point you mention below, braces...

Ah yes, of course.  Well, it's a lot simpler for me to avoid the @verb
hack, and @...char seems cleaner anyway.

    Should all the other @-commands be passed as is or lead to an error?
    My understanding is that they should lead to an error.  That is the
    following is not correct:
      @inlineraw{html, mail: address@hidden in html @rbracechar{}}

Um.  I hadn't thought about that.  I suppose @inlineraw should behave
the same as the raw environments (@html, etc.).  In the manual we merely
have this terse statement:

  In all cases, the exception to the raw processing is that `@' is still
  an escape character, so the address@hidden' command can be recognized.

which could be interpreted either way.  In practice, C makeinfo did
process commands within raw environments, e.g.,
@html
@emph{<hmph>}
@end html

outputs
<em><hmph></em>

while I see TP outputs
@emph{<hmph>}


Clearly there some commands that don't make inside raw environments
(@node comes to mind immediately), but I think the straightforward
markup commands do.  Ultimately this comes from @tex, where one
definitely wants to be able to access the Texinfo commands to do
formatting.

I don't know of any practical cases of raw Info/HTML/etc. where it
matters, so we could perhaps do things differently if it means a lot of
new work for you.  Since raw formatter commands are seldom used in the
first place.

    but the following is correct:
    @inlineraw{html, mail: address@hidden in html @rbracechar{}}

Definitely, since that's the whole point of those @...char commands.

    Those new commands could also help in user defined macro call since they

That's also a hope, yes.

Thanks,
karl