bug#42753: 26.3; `info-lookup.el': Add all manuals delivered by `emacs -Q', for `emacs-lisp-mode'

[Drew Adams]

> Wouldn't it make much more sense to make the :regexp attribute more
> specialized for the non-core manuals?  AFAIU, your proposal will
> greatly slow down "C-h S" in emacs-lisp-mode, because of the need to
> scan many more indices, and for no good reason AFAICT.
> 
> > ["(efaq-w32)Indexes" should probably be included conditionally, for MS
> > Windows.  And perhaps on other platforms `emacs -Q' gives a different
> > set of manuals, so other adjustments could be made.]
> 
> That would be sub-optimal, IMO, because questions specific to certain
> platforms can be asked and answered by people who run on other
> platforms.  Instead, we should be more selective in the regexps that
> match symbols; for example, a symbol that starts with "w32-" should
> trigger search in efaq-w32 as well.

Feel free to make any such adjustments you feel are
appropriate.

I got into this because I discovered that functions
etc. in the Dired-X manual weren't handled.
___

FWIW and IIUC, it's not really about "`C-h S' _in_
emacs-lisp-mode".  It's about Emacs-Lisp symbols in
manuals (indexes of manuals).  The Dired-X manual,
for instance, is not at all about Emacs-Lisp mode.

A separate info-lookup feature looks at the current
mode and takes it into account.  IIUC, there's nothing
in info-look.el that requires or assumes that the
current mode determines the kind of things to look up.

For example, a 3rd-party library that provides a link
for manual look-up when in `C-h f' *Help* (and there
are a few such libraries) does not make any use of the
current mode (which is `help-mode').  `C-h f' is about
Elisp functions, so the manuals to look in are those
that have entries for Elisp functions in one or more
indexes.
___

And as I said in the bug report, I may misunderstand
but it seems like there is no easy/good way for a
user or library to simply extend the predefined
behavior to, say, cover another manual (whose index
has Elisp symbols).  It seems like the behavior is
essentially chiseled in stone when info-look.el is
loaded - a once-and-for-all configuration of which
manuals to check.

If I understand that correctly, then that's the real,
underlying bug that should be fixed (not just fix the
predefined list of manuals handled).  If it were easy
to simply "add" a manual (e.g. Dired-X) to those
handling Elisp symbols then users and 3rd-party code
could do that.  Similarly, for subtracting a manual etc.

They could, themselves optimize (or not) any choice
or conditionalization of manual inclusion, and the
same for the regexps to use.

IOW, a proper bug fix (IIUC what's happening) would
be to give users easy control over info-lookup
behavior.  I'd be happy to learn that I'm mistaken
and that's already the case - and how to do that.
I didn't find it so.