On Thu, Oct 22, 2026 at 12:48:00PM +0300, Eli Zaretskii wrote: > > From: Gavin Smith <[email protected]> > > Date: Thu, 22 Oct 2026 10:19:26 +0100 > > Cc: [email protected] > > > > > Even though <entry text> is followed by a colon, it may itself > > > contain colons, so Info readers should try to include as much of the > > > line as possible in the <entry text>. (However, <entry text> may not > > > contain the ‘DEL’ characters that may occur in <node-spec>.) > > > > > > This seems to say that "<entry text>" does NOT follow the conventions > > > of menus, where menu entry text is quoted if it includes colons (and > > > other special characters). But then an Index is not "just a menu", > > > and so the "* Menu:" heading at the beginning of Index nodes is at > > > least misleading. > > > > Yes, index entries should be treated differently. > > > > I reported an Emacs "bug" about this: > > https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-01/msg00235.html > > Is it possible to remove this special formatting of menus in Index > nodes? It makes the job of detecting and parsing menu entries > significantly more complex than it already is, at least in Emacs. > > And what is the reason for this special formatting? why cannot the > menus in Index nodes use the same conventions as in other menus?
The point was to avoid using the DEL quoting mechanism when it was not necessary. It would allow you to have an index entry (from my email above): * a::b: a colon b. (line 129) With the DEL quoting, this would become * ^?a::b^?: a colon b. (line 129) As I found in my email above, Emacs Info already had some limited support for colons in index entries: The Emacs Info mode supports single colons in index entries as long as they are not followed by a space. Not quoting the index text would allow this support to continue. If we'd started output quoting entries, so that the following: * c:d: EEEE. (line 129) became * ^?c:d^?: EEEE. (line 129) - this would have broken such entries with Emacs Info mode. 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. Basically, support for this depends on using special code for reading index entries, rather than that used for other menu entries. We have a slightly more complicated implementation (not unbearbly so, in my opinion) for the sake of supporting the valuable feature of supporting colons in index entries. We could change the Info browser to support quoted index text, but there wouldn't be any immediate reason to make texi2any output such quoted text. The only reason would be if Emacs Info mode recognised the quoted index text but didn't recognise unquoted index text containing a colon. This would depend on such versions of Emacs becoming prevalent. > > > Am I missing something, or is the above Index entry incorrect due to > > > some bug in texi2any? If such entries are correct, then it is > > > impossible for an Info reader to treat Index nodes as menus, and some > > > other strategy (but which one?) is needed for Index nodes. And if > > > this is indeed the case, what is the reason for the different > > > formatting of the menus in Index nodes? > > > > The recommendation was that Info resaders should use the last colon in > > the line, not the first. This was to support index entries with colons > > in them, assuming the node name doesn't contain a colon. > > Yes, but now node names _can_ include colons, as the example I posted > clearly shows. So looking for a colon is no longer reliable, and > quoting solves this problem cleanly.
