On Fri, Mar 13, 2026 at 03:00:47PM +0100, Patrice Dumas wrote:
> On Mon, Mar 09, 2026 at 07:43:12PM +0100, Patrice Dumas wrote:
> >
> > My feeling is that it would be more consistent, when there is
> > spaces_before_argument/spaces_after_argument, to have all the spaces
> > together, though not in the same text element. So
> > spaces_before_argument and spaces_after_argument should become arrays of
> > text elements.
>
> I realized that there is another case which should be taken into
> account, a comment at end of line after/before the spaces, like
>
> @uref{ @c a comment
> aaaa @c another one
> , b}
>
> I am starting to wonder if it wouldn't be better to leave all the spaces
> and comments as regular content in brace commands in the tree and let
> the converter remove leading spaces and trailing spaces, by
> calling a function that modifies the tree, by removing spaces after
> conversion of each of the arguments, or by having a state where spaces
> are ignored (which would not be really fit for removing trailing spaces,
> actually).
>
> Any idea on that subject?
The example you give, with @c comments inside a braced argument, would
not work with texinfo.tex. For @c to read until the end of the line
it needs to change the category code of the end-of-line character and
use this to delimit its argument. However, when the braced argument is
read, all the characters are read from the input file and assigned category
codes at that time. The @c command would not get an argument until the
end of the line correctly. So for your example, there is no argument from
consistency with TeX processing as to what it should mean, other than that
it is erroneous input. The same would be true of other line commands,
such as @cindex, used inside braced arguments.
(These line commands may work inside some commands taking arguments in
braces depending on how they are implemented in texinfo.tex: I would
expect them to work inside @footnote, for example. It depends if the
braced argument is absorbed as an argument to a TeX macro. @footnote can
contain multiple paragraphs in its argument so is a different kind of
command to @uref.)
I don't know the full implications of the change you suggest but if
it complicates the program it doesn't seem justified, as @c shouldn't
be used in such contexts anyway.
If it is a comment character, it is a different matter. If "%" is
replaced with character 0x7f (DEL) in the following, the input lines
end up with trailing whitespace after the comments are removed. The
comment is removed at an early stage of processing and does not
end up as part of the macro argument.
@uref{ % a comment
aaaa % another one
, b}
>
> In any case, I do not think that it is a good idea to mark leading
> spaces for each line especially.
>
> --
> Pat
