merge 81114 34023 thanks > Cc: [email protected], [email protected] > From: Dan Jacobson <[email protected]> > Date: Mon, 25 May 2026 21:19:14 +0800 > > OK, I'll Cc: [email protected] . I'm sure they'll take care of it. Thanks. > >>>>> "GS" == Gavin Smith <[email protected]> writes: > GS> On Sun, May 24, 2026 at 04:51:17AM +0800, Dan Jacobson wrote: > >> In (info "(make) Concept Index") some of these are not linked. > >> > >> * -w, disabling: -w Option. (line 20) > >> * ,v (RCS file extension): Catalogue of Rules. (line 162) > >> * :: rules (double-colon): Double-Colon. (line 6) > >> * :::=: Immediate Assignment.(line 6) > >> * :::= <1>: Setting. (line 6) > >> * ::=: Simple Assignment. (line 9) > >> * ::= <1>: Setting. (line 6) > >> * :=: Simple Assignment. (line 9) > >> * := <1>: Setting. (line 6) > >> > > GS> They are linked with the standalone info reader, but not as far as I know > GS> with Emacs Info mode. This is a possible improvement for Emacs developers > GS> to make. I reported this as a bug in 2019: > > GS> There is a fairly simple solution to this problem that I haven't seen > GS> suggested in all the messages posted on this topic in the mailing list > GS> archives. In index nodes only (which have a special marker included, > GS> ^@^H[index^@^H]), use a colon to terminate the text of the index entry, > GS> but instead of looking for the first colon in the line, look for the > GS> last. So this entry: > > GS> * a::b: a colon b. (line 129) > > GS> would refer to line 129 of the node "a colon b". This is possible > GS> because node names cannot contain colons. This restriction is not too > GS> important, whereas the inability to index items containing colons is > GS> quite important. This is what is implemented in the standalone info > GS> browser (since change on 2017-04-08). > > GS> https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-01/msg00235.html > > GS> I suggest chasing the Emacs developers to see if they are interested > GS> in implementing this interpretation of such index entries.
This is an existing bug#34023, so opening a new bug was unnecessary.
