Re: spec for @inlinehtml etc.

[Karl Berry]

Finally back on @inlinehtml, etc., here is what was natural to implement
in texinfo.tex (not yet committed pending your thoughts):

Basic command:
  @inlinefmt{tex,Processed inline @TeX{}.}

Commas aren't a problem because @inlinefmt always has exactly two args:
  @inlinefmt{tex,Processed inline @TeX{}, with a comma.}

I think spaces should be ignored after the argument-separating comma,
but not ignored at the end of the argument text:
  Before inline w/ spaces:@inlinefmt{tex, Processed with spaces }:after inline
  -> ...spaces:Processed with spaces :after...

The expansion is the empty string if we're not in the right format:
  before html:@inlinefmt{html,This is processed, HTML.}:after html.
  -> before html::after html.


Then another command for the raw version (still ignoring spaces after
the first comma):
  @inlineraw{tex, This is raw \TeX.}

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.


Now, one more point of discussion: braces.  As far as TeX goes, 
literal braces have to be balanced, even when the text is ignored.
Consider:
  @inlineraw{html, This is {HTML}
One might think the text should be ignored by texinfo.tex, but it causes
an error.

Although I could manage to deal with that, with enough work, it seemed
pointless, because suppose one wanted a literal *right* brace:
  @inlineraw{html, This is }HTML}

This can't possibly work in any format because the } marks the end of
the argument text, by definition.  (An issue that doesn't arise with the
environment form of the conditionals.)


Therefore, I think the best approach is to define @-commands for all
Texinfo special chars to output those characters as text.  (As we've
discussed in the past, this idea has come up before in other situations,
too.)  Are there others besides these?

  @atchar{}        -> @
  @lbracechar{}    -> {
  @rbracechar{}    -> }
  @backslashchar{} -> \
We already have @comma{}, which doesn't fit the @*char{} pattern, but
it doesn't seem worth adding a synonym to me.

Wdyt?


Once we concur on the final form of all this, I'll write up the doc, etc.

Thanks,
karl