GNU bug report logs - #28607
27.0.50; help-fns unsolicited elisp loading

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28607 in the body.
You can then email your comments to 28607 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark Oteiza <mvoteiza <at> udel.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; help-fns unsolicited elisp loading
Date: Tue, 26 Sep 2017 08:49:33 -0400

Following up from
https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00773.html

Message #10 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Tue, 26 Sep 2017 11:40:53 -0400

Why did you close 28048 as fixed and open this new report?
It's the same thing.

Message #13 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Mark Oteiza <mvoteiza <at> udel.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Tue, 26 Sep 2017 11:51:26 -0400

On 26/09/17 at 11:40am, Glenn Morris wrote:
> Why did you close 28048 as fixed and open this new report?
> It's the same thing.

You're right. I should have just retitled the old report.

Message #20 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: rgm <at> gnu.org, 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Mon, 02 Jul 2018 20:57:39 +0300

> Date: Tue, 26 Sep 2017 11:51:26 -0400
> From: Mark Oteiza <mvoteiza <at> udel.edu>
> Cc: 28607 <at> debbugs.gnu.org
> 
> On 26/09/17 at 11:40am, Glenn Morris wrote:
> > Why did you close 28048 as fixed and open this new report?
> > It's the same thing.
> 
> You're right. I should have just retitled the old report.

As bug#28048 is marked "done", should this one be closed as well?

Message #23 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Mark Oteiza <mvoteiza <at> udel.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Mon, 2 Jul 2018 14:05:14 -0400

On Mon, Jul 2, 2018 at 1:57 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Tue, 26 Sep 2017 11:51:26 -0400
>> From: Mark Oteiza <mvoteiza <at> udel.edu>
>> Cc: 28607 <at> debbugs.gnu.org
>>
>> On 26/09/17 at 11:40am, Glenn Morris wrote:
>> > Why did you close 28048 as fixed and open this new report?
>> > It's the same thing.
>>
>> You're right. I should have just retitled the old report.
>
> As bug#28048 is marked "done", should this one be closed as well?

No, as I wrote previously, it probably would have made more sense to
retitle bug#28048.  Evidently this was ignored for the 26 release, so
now I'm not sure what the point of blocking bugs is.

Message #26 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: rgm <at> gnu.org, 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Mon, 02 Jul 2018 21:16:34 +0300

> From: Mark Oteiza <mvoteiza <at> udel.edu>
> Date: Mon, 2 Jul 2018 14:05:14 -0400
> Cc: Glenn Morris <rgm <at> gnu.org>, 28607 <at> debbugs.gnu.org
> 
> >> On 26/09/17 at 11:40am, Glenn Morris wrote:
> >> > Why did you close 28048 as fixed and open this new report?
> >> > It's the same thing.
> >>
> >> You're right. I should have just retitled the old report.
> >
> > As bug#28048 is marked "done", should this one be closed as well?
> 
> No, as I wrote previously, it probably would have made more sense to
> retitle bug#28048.

So "it's the same thing" above is inaccurate or incorrect?  (The title
doesn't bother me, only the essence.)

> Evidently this was ignored for the 26 release, so now I'm not sure
> what the point of blocking bugs is.

It wasn't ignored.  But as no one seemed to want to pick up the
gauntlet, and since my assessment of the bug's severity was that it's
relatively minor, I saw no reason to block the release due to it.

Message #29 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Mon, 02 Jul 2018 21:29:46 -0400

What do you actually want to happen with this report?
The feature is working as designed.
Do you eg want an option to turn it off?
(The existing help-enable-auto-load could perhaps be extended for this.)

Message #32 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Mark Oteiza <mvoteiza <at> udel.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Mon, 16 Jul 2018 09:03:36 -0400

On Mon, Jul 2, 2018 at 9:29 PM, Glenn Morris <rgm <at> gnu.org> wrote:
>
> What do you actually want to happen with this report?
> The feature is working as designed.
> Do you eg want an option to turn it off?
> (The existing help-enable-auto-load could perhaps be extended for this.)

At minimum an option to disable it, which is what I'm already doing as
a workaround.  I don't consider loading elisp totally unrelated to a
symbol I'm introspecting to be a feature.  Though, one benefit has
been revealing ill-behaved elisp in CEDET.

Message #35 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Wed, 15 May 2019 22:12:34 -0400

[Message part 1 (text/plain, inline)]

tags 28607 + patch
unarchive 28048
notfixed 28048 26.1
forcemerge 28607 28048
quit

Mark Oteiza <mvoteiza <at> udel.edu> writes:

> On Mon, Jul 2, 2018 at 9:29 PM, Glenn Morris <rgm <at> gnu.org> wrote:
>>
>> What do you actually want to happen with this report?
>> The feature is working as designed.
>> Do you eg want an option to turn it off?
>> (The existing help-enable-auto-load could perhaps be extended for this.)
>
> At minimum an option to disable it, which is what I'm already doing as
> a workaround.

Right, here's patch for that.  I made a new option instead of extending
help-enable-auto-load because otherwise I would have to think about how
to dis/enable them each individually, which is annoying to encode in a
single option.

[0001-Add-option-to-disable-help-completion-autoloading-Bu.patch (text/x-diff, inline)]

From 2e3d84fc1d8457046a0aceed7e1f9837330a4365 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Wed, 15 May 2019 20:29:38 -0400
Subject: [PATCH] Add option to disable help completion autoloading (Bug#28607)

* lisp/help-fns.el (help-enable-completion-auto-load): New option.
(help--symbol-completion-table): Consult it.
* etc/NEWS: Announce it.
---
 etc/NEWS         |  6 ++++++
 lisp/help-fns.el | 18 +++++++++++++++---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 573c8236b2..286f9ee275 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -24,6 +24,12 @@ with a prefix argument or by typing 'C-u C-h C-n'.
 
 * Changes in Emacs 26.3
 
+---
+** New option 'help-enable-completion-auto-load'.
+This allows disabling the new feature introduced in Emacs 26.1 which
+loads files during completion of 'C-h f' and 'C-h v' according to
+'definition-prefixes'.
+
 
 * Editing Changes in Emacs 26.3
 
diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index a7812e3b4b..8684a853af 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -89,11 +89,23 @@ help--load-prefixes
       (unless (help--loaded-p file)
         (load file 'noerror 'nomessage)))))
 
+(defcustom help-enable-completion-auto-load t
+  "Whether completion for Help commands can perform autoloading.
+If non-nil, whenever invoking completion for `describe-function'
+or `describe-variable' load files that might contain definitions
+with the current prefix.  The files are chosen according to
+`definition-prefixes'."
+  :type 'boolean
+  :group 'help
+  :version "26.3")
+
 (defun help--symbol-completion-table (string pred action)
-  (let ((prefixes (radix-tree-prefixes (help-definition-prefixes) string)))
-    (help--load-prefixes prefixes))
+  (when help-enable-completion-auto-load
+    (let ((prefixes (radix-tree-prefixes (help-definition-prefixes) string)))
+      (help--load-prefixes prefixes)))
   (let ((prefix-completions
-         (mapcar #'intern (all-completions string definition-prefixes))))
+         (and help-enable-completion-auto-load
+              (mapcar #'intern (all-completions string definition-prefixes)))))
     (complete-with-action action obarray string
                           (if pred (lambda (sym)
                                      (or (funcall pred sym)
-- 
2.11.0

Message #42 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: mvoteiza <at> udel.edu, rgm <at> gnu.org, 28607 <at> debbugs.gnu.org
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Thu, 16 May 2019 16:38:24 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Glenn Morris <rgm <at> gnu.org>,  Eli Zaretskii <eliz <at> gnu.org>,  28607 <at> debbugs.gnu.org
> Date: Wed, 15 May 2019 22:12:34 -0400
> 
> > At minimum an option to disable it, which is what I'm already doing as
> > a workaround.
> 
> Right, here's patch for that.  I made a new option instead of extending
> help-enable-auto-load because otherwise I would have to think about how
> to dis/enable them each individually, which is annoying to encode in a
> single option.

Thanks, this LGTM.  I wonder whether we should document
definition-prefixes (together with the mechinery it is part of) and
this new option in the ELisp manual.

Message #45 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mvoteiza <at> udel.edu, rgm <at> gnu.org, 28607 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Sat, 18 May 2019 12:00:52 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> I made a new option instead of extending help-enable-auto-load
>> because otherwise I would have to think about how to dis/enable them
>> each individually, which is annoying to encode in a single option.
>
> Thanks, this LGTM.  I wonder whether we should document
> definition-prefixes (together with the mechinery it is part of) and
> this new option in the ELisp manual.

Yeah, I think the machinery deserves a mention in the Elisp manual at
least.  Though the user option should go in the Emacs manual.

--- c/doc/emacs/building.texi
+++ i/doc/emacs/building.texi
@@ -1499,6 +1499,12 @@ Lisp Libraries
 buffer).  To disable this feature, change the variable
 @code{help-enable-auto-load} to @code{nil}.
 
+@vindex help-enable-completion-auto-load
+Automatic loading also occurs when completing names for
+@code{describe-variable} and @code{describe-function}, based on the
+prefix being completed.  To disable this feature, change the variable
+@code{help-enable-completion-auto-load} to @code{nil}.
+
 @vindex load-dangerous-libraries
 @cindex Lisp files byte-compiled by XEmacs
   By default, Emacs refuses to load compiled Lisp files which were
diff --git c/doc/lispref/loading.texi i/doc/lispref/loading.texi
index f0cc689d1f..947f1fa6a5 100644
--- c/doc/lispref/loading.texi
+++ i/doc/lispref/loading.texi
@@ -466,9 +466,11 @@ Autoload
 order to install the real definition and other associated code, then
 runs the real definition as if it had been loaded all along.
 Autoloading can also be triggered by looking up the documentation of
-the function or macro (@pxref{Documentation Basics}).
+the function or macro (@pxref{Documentation Basics}), and completion
+of variable and function names (@pxref{Autoload by Prefix} below).
 
 @menu
+* Autoload by Prefix:: Autoload by Prefix.
 * When to Autoload::   When to Use Autoload.
 @end menu
 
@@ -703,6 +705,23 @@ Autoload
 function, only a macro.
 @end defun
 
+@node Autoload by Prefix
+@subsection Autoload by Prefix
+
+@vindex definition-prefixes
+@findex register-definition-prefixes
+@vindex autoload-compute-prefixes
+During completion for the commands @code{describe-variable} and
+@code{describe-function}, Emacs will try to load files which may
+contain definitions matching the prefix being completed.  The variable
+@code{definition-prefixes} holds a hashtable which maps a prefix to
+the corresponding list of files to load for it.  Entries to this
+mapping are added by calls to @code{register-definition-prefixes}
+which are generated by @code{update-file-autoloads}.  Files which
+don't contain any definitions worth loading (test files, for
+examples), should set @code{autoload-compute-prefixes} to @code{nil}
+as a file-local variable.
+
 @node When to Autoload
 @subsection When to Use Autoload
 @cindex autoload, when to use

Message #48 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: mvoteiza <at> udel.edu, rgm <at> gnu.org, 28607 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Sat, 18 May 2019 19:15:40 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: mvoteiza <at> udel.edu,  rgm <at> gnu.org,  28607 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Sat, 18 May 2019 12:00:52 -0400
> 
> > Thanks, this LGTM.  I wonder whether we should document
> > definition-prefixes (together with the mechinery it is part of) and
> > this new option in the ELisp manual.
> 
> Yeah, I think the machinery deserves a mention in the Elisp manual at
> least.  Though the user option should go in the Emacs manual.

Thanks, this LGTM.  A couple of minor nits:

> +@node Autoload by Prefix
> +@subsection Autoload by Prefix

I think a "@cindex autoload by prefix" would be good here.

> +During completion for the commands @code{describe-variable} and
> +@code{describe-function}, Emacs will try to load files which may
> +contain definitions matching the prefix being completed.  The variable
> +@code{definition-prefixes} holds a hashtable which maps a prefix to
> +the corresponding list of files to load for it.  Entries to this
> +mapping are added by calls to @code{register-definition-prefixes}
> +which are generated by @code{update-file-autoloads}.  Files which
> +don't contain any definitions worth loading (test files, for
> +examples), should set @code{autoload-compute-prefixes} to @code{nil}
> +as a file-local variable.

I would add a cross-reference to where update-file-autoloads is
described after it's mentioned.

Message #51 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mvoteiza <at> udel.edu, rgm <at> gnu.org, 28607 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Mon, 20 May 2019 13:49:34 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> +@node Autoload by Prefix
>> +@subsection Autoload by Prefix
>
> I think a "@cindex autoload by prefix" would be good here.

Sure.

>> +During completion for the commands @code{describe-variable} and
>> +@code{describe-function}, Emacs will try to load files which may
>> +contain definitions matching the prefix being completed.  The variable
>> +@code{definition-prefixes} holds a hashtable which maps a prefix to
>> +the corresponding list of files to load for it.  Entries to this
>> +mapping are added by calls to @code{register-definition-prefixes}
>> +which are generated by @code{update-file-autoloads}.  Files which
>> +don't contain any definitions worth loading (test files, for
>> +examples), should set @code{autoload-compute-prefixes} to @code{nil}
>> +as a file-local variable.
>
> I would add a cross-reference to where update-file-autoloads is
> described after it's mentioned.

Um, how should I do this?  I tried (I've also added
@anchor{update-file-autoloads} below @findex update-file-autoloads):

    the corresponding list of files to load for it.  Entries to this
    mapping are added by calls to @code{register-definition-prefixes}
    which are generated automatically (@pxref{update-file-autoloads,
    @code{update-file-autoloads}}).  Files which don't contain any

But it looks rather strange, it adds an extra period.

    corresponding list of files to load for it.  Entries to this mapping
    are added by calls to `register-definition-prefixes' which are
    generated automatically (*note `update-file-autoloads'
    .).  Files which don't contain any definitions

Message #54 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: mvoteiza <at> udel.edu, rgm <at> gnu.org, 28607 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Mon, 20 May 2019 20:01:08 +0100

On May 20, 2019 6:49:34 PM GMT+01:00, Noam Postavsky <npostavs <at> gmail.com> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> +@node Autoload by Prefix
> >> +@subsection Autoload by Prefix
> >
> > I think a "@cindex autoload by prefix" would be good here.
> 
> Sure.
> 
> >> +During completion for the commands @code{describe-variable} and
> >> +@code{describe-function}, Emacs will try to load files which may
> >> +contain definitions matching the prefix being completed.  The
> variable
> >> +@code{definition-prefixes} holds a hashtable which maps a prefix
> to
> >> +the corresponding list of files to load for it.  Entries to this
> >> +mapping are added by calls to @code{register-definition-prefixes}
> >> +which are generated by @code{update-file-autoloads}.  Files which
> >> +don't contain any definitions worth loading (test files, for
> >> +examples), should set @code{autoload-compute-prefixes} to
> @code{nil}
> >> +as a file-local variable.
> >
> > I would add a cross-reference to where update-file-autoloads is
> > described after it's mentioned.
> 
> Um, how should I do this?  I tried (I've also added
> @anchor{update-file-autoloads} below @findex update-file-autoloads):
> 
>     the corresponding list of files to load for it.  Entries to this
>     mapping are added by calls to @code{register-definition-prefixes}
>     which are generated automatically (@pxref{update-file-autoloads,
>     @code{update-file-autoloads}}).  Files which don't contain any
> 
> But it looks rather strange, it adds an extra period.
> 
>   corresponding list of files to load for it.  Entries to this mapping
>     are added by calls to `register-definition-prefixes' which are
>     generated automatically (*note `update-file-autoloads'
>     .).  Files which don't contain any definitions

You don't hzve to add @anchor, it's good enough to point to the node.

Message #57 received at 28607 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mvoteiza <at> udel.edu, rgm <at> gnu.org, 28607 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#28607: 27.0.50; help-fns unsolicited elisp loading
Date: Tue, 21 May 2019 07:45:23 -0400

tags 28607 fixed
close 28607 26.3
quit

>> > I think a "@cindex autoload by prefix" would be good here.

>> > I would add a cross-reference to where update-file-autoloads is
>> > described after it's mentioned.

> You don't hzve to add @anchor, it's good enough to point to the node.

Ah right, that would be simpler.  Done and pushed to emacs-26.

400907b3c1 2019-05-21T07:37:22-04:00 "Add option to disable help completion autoloading (Bug#28607)"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=400907b3c1d94359dda38ad5f416829567d6e478

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.