On Thu, Oct 22, 2026 at 11:36:53AM +0100, Gavin Smith wrote:
> Looking at the source code of the standalone Info browser, it does not
> appear set up to handle DEL-quoted index entries. Index entries are dealt
> with as a special case. So if we changed texi2any to surround with DEL bytes
> the text of an index entry that contained a colon, then no previously released
> Info browser would be able to read such an entry. It does not seem justified
> to create such a breakage merely for the difficulty of implementation in
> Emacs Info mode.
I had another look at the source code for Info and such quoted index
entries such as the following actually work, although texi2any won't
produce such index entries:
* ^?Texinfo::Convert::Converter initialization^?: ^?Texinfo::Convert::Converter
Converter Initialization^?.
In scan.c:scan_reference_label:
if (!in_index || inptr[label_len] == INFO_QUOTE)
{
len = read_quoted_string (inptr + label_len, ":", max_lines,
&entry->nodename);
canonicalize_whitespace (entry->nodename);
if (!len && !entry->filename)
return 0; /* Input invalid. */
label_len += len;
}
else
{
/* If in an index node, go forward to the last colon on the line
(not preceded by a newline, NUL or DEL). This is in order to
support index entries containing colons. This should work fine
as long as the node name does not contain a colon as well. */
It's handled by the first condition as (inptr[label_len] == INFO_QUOTE) is
true.
So we could consider changing texi2any to output quoting DELs for the index
entry text, too (now that Emacs supports these, thanks to Eli).
One possibility is to double check what exactly Emacs supported before, and
only output the DELs for input that Emacs didn't support. I belive if there
was only a single colon not followed by whitespace, Emacs managed to treat
it as an index entry.
There's no downside in outputting the DELs in other cases, as far as I can
tell: where there is a double colon ("::") or colon followed by space (": ").
