bug#28607: 27.0.50; help-fns unsolicited elisp loading

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Mark Oteiza]

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

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Glenn Morris]

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

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Mark Oteiza]

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.

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Eli Zaretskii]

> Date: Tue, 26 Sep 2017 11:51:26 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: 28607@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?

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Mark Oteiza]

On Mon, Jul 2, 2018 at 1:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 26 Sep 2017 11:51:26 -0400
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Cc: 28607@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.

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Mon, 2 Jul 2018 14:05:14 -0400
> Cc: Glenn Morris <rgm@gnu.org>, 28607@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.

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Glenn Morris]

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

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Mark Oteiza]

On Mon, Jul 2, 2018 at 9:29 PM, Glenn Morris <rgm@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.

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

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

Mark Oteiza <mvoteiza@udel.edu> writes:

> On Mon, Jul 2, 2018 at 9:29 PM, Glenn Morris <rgm@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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 2333 bytes --]

From 2e3d84fc1d8457046a0aceed7e1f9837330a4365 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@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'.
 \f
 * 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'.
+
 \f
 * 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

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Glenn Morris <rgm@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,  28607@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.

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Noam Postavsky]

Eli Zaretskii <eliz@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

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: mvoteiza@udel.edu,  rgm@gnu.org,  28607@debbugs.gnu.org, Stefan Monnier <monnier@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.

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Noam Postavsky]

Eli Zaretskii <eliz@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

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Eli Zaretskii]

On May 20, 2019 6:49:34 PM GMT+01:00, Noam Postavsky <npostavs@gmail.com> wrote:
> Eli Zaretskii <eliz@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.

bug#28607: 27.0.50; help-fns unsolicited elisp loading

[Noam Postavsky]

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