bug#3692: 23.0.95; `i' in Info, when in multiple indexes but same target

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 03 Jun 2021 11:56:15 +0200
> Cc: 3692@debbugs.gnu.org
> 
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
> > When a matching entry is found in more than one index (or more than
> > once in the same index), you get a message such as the following:
> >
> > Found `truncate-lines' in Variable Index.  (2 total; use `,' for next)
> 
> I've now changed this to remove the duplicates in Emacs 28.

I think this change is incorrect, and should be reverted.  An Info
manual cannot possibly have duplicate index entries; if the Texinfo
source does have such duplicate entries, 'makeinfo' will rename them
by appending a numeric "<n>" tail.

The code which was modified tries to look for partial matches to what
the user typed at the 'i's prompt, and that _can_ indeed include
duplicates where what the user typed matches a substring of some index
entry.  But those duplicates cannot be removed, because then Info will
not show all the matches.  For example, in this case the 2 matches are
"truncate-lines" and "toggle-truncate-lines"; with the change just
installed, Emacs shows only one of them, and typing ',' doesn't help
to show the other one.

Going back to the original report:

> When all of the targets are identical, or even when they are in the
> same node, this message is not too helpful. Repeated use of `,' stays
> in the same node.

If this happens, it's a bug in the indexing, not in the Info reader:
similar, let alone identical, index entry in the same node, especially
when they are close to each other, should be avoided.

> On the other hand, it can be helpful to know that the same term is an
> entry in both the Command index and the Variable index (for example).

The response to multiple matches says how many matches it found and
shows the first of them with its node.  Other nodes will be shown when
you type ','.  there isn't enough screen estate in the echo area to
show each match with its node (and I personally think the node in
which you find a match is not very important for the purpose that the
index-search serves).

So I think there's nothing we should do about this bug report, except
being vigilant to patches that introduce similar index entries close
to one another.