* bug#28607: 27.0.50; help-fns unsolicited elisp loading @ 2017-09-26 12:49 Mark Oteiza 2017-09-26 15:40 ` Glenn Morris 0 siblings, 1 reply; 15+ messages in thread From: Mark Oteiza @ 2017-09-26 12:49 UTC (permalink / raw) To: 28607 Following up from https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00773.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2017-09-26 12:49 bug#28607: 27.0.50; help-fns unsolicited elisp loading Mark Oteiza @ 2017-09-26 15:40 ` Glenn Morris 2017-09-26 15:51 ` Mark Oteiza 0 siblings, 1 reply; 15+ messages in thread From: Glenn Morris @ 2017-09-26 15:40 UTC (permalink / raw) To: Mark Oteiza; +Cc: 28607 Why did you close 28048 as fixed and open this new report? It's the same thing. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2017-09-26 15:40 ` Glenn Morris @ 2017-09-26 15:51 ` Mark Oteiza 2018-07-02 17:57 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Mark Oteiza @ 2017-09-26 15:51 UTC (permalink / raw) To: Glenn Morris; +Cc: 28607 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2017-09-26 15:51 ` Mark Oteiza @ 2018-07-02 17:57 ` Eli Zaretskii 2018-07-02 18:05 ` Mark Oteiza 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2018-07-02 17:57 UTC (permalink / raw) To: Mark Oteiza; +Cc: 28607 > 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2018-07-02 17:57 ` Eli Zaretskii @ 2018-07-02 18:05 ` Mark Oteiza 2018-07-02 18:16 ` Eli Zaretskii 2018-07-03 1:29 ` Glenn Morris 0 siblings, 2 replies; 15+ messages in thread From: Mark Oteiza @ 2018-07-02 18:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28607 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2018-07-02 18:05 ` Mark Oteiza @ 2018-07-02 18:16 ` Eli Zaretskii 2018-07-03 1:29 ` Glenn Morris 1 sibling, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2018-07-02 18:16 UTC (permalink / raw) To: Mark Oteiza; +Cc: 28607 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2018-07-02 18:05 ` Mark Oteiza 2018-07-02 18:16 ` Eli Zaretskii @ 2018-07-03 1:29 ` Glenn Morris 2018-07-16 13:03 ` Mark Oteiza 1 sibling, 1 reply; 15+ messages in thread From: Glenn Morris @ 2018-07-03 1:29 UTC (permalink / raw) To: Mark Oteiza; +Cc: 28607 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.) ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2018-07-03 1:29 ` Glenn Morris @ 2018-07-16 13:03 ` Mark Oteiza 2019-05-16 2:12 ` Noam Postavsky 0 siblings, 1 reply; 15+ messages in thread From: Mark Oteiza @ 2018-07-16 13:03 UTC (permalink / raw) To: Glenn Morris; +Cc: 28607 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2018-07-16 13:03 ` Mark Oteiza @ 2019-05-16 2:12 ` Noam Postavsky 2019-05-16 13:38 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Noam Postavsky @ 2019-05-16 2:12 UTC (permalink / raw) To: Mark Oteiza; +Cc: 28607 [-- 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 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2019-05-16 2:12 ` Noam Postavsky @ 2019-05-16 13:38 ` Eli Zaretskii 2019-05-18 16:00 ` Noam Postavsky 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2019-05-16 13:38 UTC (permalink / raw) To: Noam Postavsky; +Cc: mvoteiza, 28607 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2019-05-16 13:38 ` Eli Zaretskii @ 2019-05-18 16:00 ` Noam Postavsky 2019-05-18 16:15 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Noam Postavsky @ 2019-05-18 16:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: mvoteiza, 28607, Stefan Monnier 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 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2019-05-18 16:00 ` Noam Postavsky @ 2019-05-18 16:15 ` Eli Zaretskii 2019-05-20 17:49 ` Noam Postavsky 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2019-05-18 16:15 UTC (permalink / raw) To: Noam Postavsky; +Cc: mvoteiza, 28607, monnier > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2019-05-18 16:15 ` Eli Zaretskii @ 2019-05-20 17:49 ` Noam Postavsky 2019-05-20 19:01 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Noam Postavsky @ 2019-05-20 17:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: mvoteiza, 28607, monnier 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2019-05-20 17:49 ` Noam Postavsky @ 2019-05-20 19:01 ` Eli Zaretskii 2019-05-21 11:45 ` Noam Postavsky 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2019-05-20 19:01 UTC (permalink / raw) To: Noam Postavsky; +Cc: mvoteiza, 28607, monnier 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#28607: 27.0.50; help-fns unsolicited elisp loading 2019-05-20 19:01 ` Eli Zaretskii @ 2019-05-21 11:45 ` Noam Postavsky 0 siblings, 0 replies; 15+ messages in thread From: Noam Postavsky @ 2019-05-21 11:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: mvoteiza, 28607, monnier 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-05-21 11:45 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-09-26 12:49 bug#28607: 27.0.50; help-fns unsolicited elisp loading Mark Oteiza 2017-09-26 15:40 ` Glenn Morris 2017-09-26 15:51 ` Mark Oteiza 2018-07-02 17:57 ` Eli Zaretskii 2018-07-02 18:05 ` Mark Oteiza 2018-07-02 18:16 ` Eli Zaretskii 2018-07-03 1:29 ` Glenn Morris 2018-07-16 13:03 ` Mark Oteiza 2019-05-16 2:12 ` Noam Postavsky 2019-05-16 13:38 ` Eli Zaretskii 2019-05-18 16:00 ` Noam Postavsky 2019-05-18 16:15 ` Eli Zaretskii 2019-05-20 17:49 ` Noam Postavsky 2019-05-20 19:01 ` Eli Zaretskii 2019-05-21 11:45 ` Noam Postavsky
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).