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

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Mark Oteiza
Reply | Threaded
Open this post in threaded view
|

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

Glenn Morris-3

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



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Date: Tue, 26 Sep 2017 11:51:26 -0400
> From: Mark Oteiza <[hidden email]>
> Cc: [hidden email]
>
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Mark Oteiza
On Mon, Jul 2, 2018 at 1:57 PM, Eli Zaretskii <[hidden email]> wrote:

>> Date: Tue, 26 Sep 2017 11:51:26 -0400
>> From: Mark Oteiza <[hidden email]>
>> Cc: [hidden email]
>>
>> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Mark Oteiza <[hidden email]>
> Date: Mon, 2 Jul 2018 14:05:14 -0400
> Cc: Glenn Morris <[hidden email]>, [hidden email]
>
> >> 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.



Reply | Threaded
Open this post in threaded view
|

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

Glenn Morris-3
In reply to this post by Mark Oteiza

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



Reply | Threaded
Open this post in threaded view
|

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

Mark Oteiza
On Mon, Jul 2, 2018 at 9:29 PM, Glenn Morris <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

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

Mark Oteiza <[hidden email]> writes:

> On Mon, Jul 2, 2018 at 9:29 PM, Glenn Morris <[hidden email]> 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.


From 2e3d84fc1d8457046a0aceed7e1f9837330a4365 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Noam Postavsky <[hidden email]>
> Cc: Glenn Morris <[hidden email]>,  Eli Zaretskii <[hidden email]>,  [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
Eli Zaretskii <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Noam Postavsky <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email], Stefan Monnier <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:

> Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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