Re: leading and trailing spaces in brace commands

[Gavin Smith]

On Sun, Sep 25, 2022 at 04:11:13PM +0200, Patrice Dumas wrote:
> 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

It would make sense to have consistent treatment for classes of commands
in tp/Texinfo/XS/parsetexi/command_data.txt.  For example, all BRACE_arguments
commands could ignore spaces, including around commas, after opening braces,
and before closing braces.

It might be better, if there is an error for @U with spaces with texinfo.tex,
to fix texinfo.tex (although not a priority), rather than have special
treatment in texi2any.

I'm not sure if it would be correct to ignore spaces for other commands:
@math, @value, @verb...  Almost every command could be different.  It
seems quite simple to say that these spaces are ignored for BRACE_arguments
commands but not for others, although needless to say I haven't fully
explored the consequences of this idea by trying to implement it.

> 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.

It's likely a minefield with every command being slightly different.  It
may be possible to get consistency with texi2any but I don't know how
easy this would be.

Generally speaking I don't think it's a very important issue and I'd
rather spend time on issues that should be resolved before the next
release, rather than spending time on obscure use cases.  Of course, if
it's something you feel is worthwhile then please feel free to work on it.