On Sun, Oct 11, 2026 at 11:40:54PM +0200, Patrice Dumas wrote:
> On Sun, Oct 11, 2026 at 10:15:19PM +0200, Patrice Dumas wrote:
> > Hello,
> >
> > I thought that @U{....} was accepted in 'contain_plain_text' @-commands,
> > but I checked the code and tested and found out that it is not the case
> > (while answering Werner on @sortas). I think that it should be. I
> > would also argue that @inlineifclear and @inlineifset could also be
> > there. @w could also have been in @sortas, but this context is also
> > for the accent command argument, in which there should not be @w.
>
> Thinking a bit more about it, it would probably better if @inlineifclear
> and @inlineifset were not there, in general they can be "outside" of the
> @-command accepting plain text only, as @-command accepting plain text
> only have small sized arguments.
>
> So that would mainly be @U.
I needed to remind myself of what "contain_plain_text" commands were.
This is for the checking of correct nesting of Texinfo commands.
Reading tta/perl/Texinfo/ParserNonXS.pm, some Texinfo commands count as
plain text: accent commands (e.g. @' for an accute accent), glyph commands
(e.g. @AA{} to insert Å), and some single byte commands (like @{ to insert
{).
It certainly seems consistent to allow @U{...} as "plain text" if @AA{}
is, as it is just another way of inserting a character. Will you take
care of adding @U to the list of allowed commands?
@U itself is not listed as contain_plain_text in tta/data/command_data.txt,
although there is a comment:
# Parsers have specific checks for U content.
So there should be no danger that a "non-plain-text" command could be
nested inside a @U command inside a "contain_plain_text" command, evading
the check for plain text.
I looked at the commands listed with "contain_plain_text" in
tta/data/command_data.txt. It may not be useful very often. You can
imagine it would be useful inside @sortas, although for some other
commands (@need) it would not be. Usage in other commands are dubious
(@defindex) or potentially confusing.
In @include, I imagine that characters with @U would have to be encoded
to whatever we think the file system encoding is (with
INPUT_FILE_NAME_ENCODING or similar).
