On Mon, Oct 12, 2026 at 09:52:37PM +0100, Gavin Smith wrote:
> I agree we shouldn't use NUL or \x{1F}. I actually don't like \x{7F}\x{08}
> because of how it appears when it would be printed to the terminal:
> "Ref: \x{7F}\x{08}Index cp" would print as "Ref:Index cp" with the space after
> the colon disappearing. (It's similar to how to the index marker
> ^@^H[index^@^H] prints as "[inde]" - see the output of
> "head -n 50 texinfo.info-4" in a terminal, for example.)
This happens because of \x{7F}, I guess because it deletes a character,
as should be. I do not think that it should be a considered as a
problem, as the control characters we use for quoting should all have
some effect when printed on terminal, more or less problematic, probably
depending on the terminal/application used. That's their function, after all.
We should just try to avoid ones that are too much of a pain (such as
NUL).
> I doubt that \x{7F} would work well as this is separates the offset from
> the anchor name and so it's likely that an Info reading program wouldn't
> be able to read an anchor name containing this byte. Indeed, I've tested
> that with a recent development version of Info, a line like
>
> Ref: ^?Index cp^?894490
>
> in the tag table of the file stops the manual being loaded at all (^? is
> the 7F byte).
Ok, let's drop \x{7F}.
> There's not really a right or wrong answer to this question. The anchor
> name can show up in the Info browser - if the user tab-completes after
> typing the 'g' command, for example, so this shouldn't be too broken if
> the Info browser doesn't have special support.
Indeed. But I think that it is the least intrusive possibility, at
least compared to other possibilities we discussed about, and should be
efficient. Also the user of an old Info reader should easily understand
that this is something special and should not necessarily be followed.
> I checked with a line like:
>
> Ref: ^HIndex cp^?894490
>
> (i.e. with a special marker SPC BS) this shows up in the tab completion
> in standalone Info after the 'g' command as "^HIndex cp" at the start
> of the list. The leading space appears to be skipped when getting the
> anchor name - so probably using a leading space isn't a good idea for this.
I do not get it.
> Another idea is to use some other control character, somewhat at random.
> "Ref: ^XIndex cp" for example. ^X doesn't appear to do anything when
> printed to a terminal, so this prints as "Ref: Index cp" if dumped to
> a terminal. In Info, after typing "g TAB", "^XIndex cp" is listed at
> the top of the completions pane, and you can select it by typing
> "^Q^XIndex cp RET". Emacs seems to work the same way.
I think that we should try to use control characters we already use if
possible, therefore I would prefer ^H to ^X.
> So I think using a "^X" byte prefix would be ok. I'm also happy with
> the idea of not using a control character at all in the anchor name.
I think that we should use a control character, and even make it a
(temporary, if 40 years can be considered temprary...) feature of the
Info format that something like
Ref: ^HIndex^H toto^?894490
is to be considered to be exactly the same as
Index: toto^?894490
and is used as a workaround for standalone Info before 2025 not accepting
unknown tag table fields to add new tag table fields. The Info readers
would also handle the new tag table field, such that it would be forward
compatible.
This would allow for a transition path: until 2045 have texi2any
output, for new tag table fields
Ref: ^HTiti^H ....^?894490
after 2045 output
Titi: ....^?894490
And in Info readers handle both forms until 2065.
--
Pat
