all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 42753@debbugs.gnu.org
Subject: bug#42753: 26.3; `info-lookup.el': Add all manuals delivered by `emacs -Q', for `emacs-lisp-mode'
Date: Sat, 8 Aug 2020 07:28:34 -0700 (PDT)	[thread overview]
Message-ID: <0d3dda22-b82e-47f0-a06d-5433ba2cf2b9@default> (raw)
In-Reply-To: <<835z9t7cme.fsf@gnu.org>>

> 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.





       reply	other threads:[~2020-08-08 14:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<d69397a7-acf7-4803-9cba-f7e0686712f4@default>
     [not found] ` <<835z9t7cme.fsf@gnu.org>
2020-08-08 14:28   ` Drew Adams [this message]
2020-08-15 14:22     ` bug#42753: 26.3; `info-lookup.el': Add all manuals delivered by `emacs -Q', for `emacs-lisp-mode' Michael Albinus
2021-08-29 22:10       ` Lars Ingebrigtsen
2021-10-08 13:36         ` Lars Ingebrigtsen
2021-10-08 14:02           ` Eli Zaretskii
2021-10-08 14:33             ` Michael Albinus
2021-10-08 16:05               ` Eli Zaretskii
2021-10-08 16:23                 ` Michael Albinus
2021-10-08 17:36                   ` Eli Zaretskii
2021-10-09 11:17                   ` Lars Ingebrigtsen
2021-10-09 12:45                     ` Lars Ingebrigtsen
2020-08-07 22:20 Drew Adams
2020-08-08  8:42 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0d3dda22-b82e-47f0-a06d-5433ba2cf2b9@default \
    --to=drew.adams@oracle.com \
    --cc=42753@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.