Hello,
I have noticed that there are inconsistencies between texi2any and
Texinfo TeX for leading spaces in some brace commands. It is not such a
big deal, we avoid being too detailed on formatting expectations, but it
would be better if the best option and maybe something more consistent
was chosen when it is possible. The main issue I see for texi2any is
that spaces in brace commands are not ignored based on the @-command
type very consistently.
Leading and trailing are not ignored in texi2any for indicating brace
@-commands, such as @code{} (and @sub, @headitemfont, @clicksequence)
and for @w.
Leading and trailing spaces are ignored in texi2any for the other brace
@-commands, including the @-commands in the following list 'U', 'dmn',
'key', 'hyphenation', 'indicateurl', 'titlefont', 'anchor', 'errormsg',
'sortas', 'seeentry', 'seealso', but also brace @-commands with more
than one argument (@ref, @image, @abbr, @url, @email) and @-command not
formatted along with the main text or in math context, @footnote,
@*caption, @math.
I suggest, for texi2any
* not to ignore spaces for indicating brace @-commands and @w (nothing
changes for those commands) and also for the following list of @-commands
that are somewhat similar to indicating @-commands:
U, dmn, key, indicateurl, titlefont.
For @U, the objective in keeping spaces is mostly to issue an error if
there are spaces (as in Texinfo TeX).
* to ignore spaces for the other brace @-commands
Any remark/objection?
It would probably be best for Texinfo TeX to do something consistent,
but it may also not be worth the time involved either. In my tests, spaces
seems to always be ignored around commas in Texinfo TeX, which is good,
trailing spaces before a closing brace are also often if not always
ignored, but a leading space is often output, for example for @email,
@abbr, and even for @shortcaption, but not for @footnote or @sortas.
--
Pat
