* bug#23002: 25.0.92; sluggish M-x
@ 2016-03-13 4:01 Leo Liu
2016-03-13 16:03 ` Drew Adams
2016-03-13 16:08 ` Eli Zaretskii
0 siblings, 2 replies; 13+ messages in thread
From: Leo Liu @ 2016-03-13 4:01 UTC (permalink / raw)
To: 23002; +Cc: Stefan Monnier
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]
1. start a NEW GUI Emacs with `emacs -q' and go to the *Scratch* buffer
2. M-x emacs-lisp-mode RET
The cursor stays in the minibuffer (see the screenshot; long enough for
me to take a screenshot) for a few seconds before the message "You can
run the command ‘emacs-lisp-mode’ with M-x e-li-mo RET".
If you repeat `M-x emacs-lisp-mode RET' the delay is gone but it will
come back at some point.
This bug makes M-x very sluggish and annoying to use. I have experienced
it since switching to 25.0.x but didn't find a simple way to reproduce
it until just now.
It surfaced because of this commit:
d94bc77ec77dea298063f182cc8a6548b6ccce81 is the first bad commit
commit d94bc77ec77dea298063f182cc8a6548b6ccce81
Author: Stefan Monnier
Date: Mon Nov 3 17:27:26 2014 -0500
* lisp/simple.el (execute-extended-command--last-typed): New var.
(read-extended-command): Set it.
Don't complete obsolete commands.
(execute-extended-command--shorter-1)
(execute-extended-command--shorter): New functions.
(execute-extended-command): Use them to suggest shorter names.
(indicate-copied-region, deactivate-mark): Use region-active-p.
:040000 040000 de3e26b5d09fab83741601a4e7207ff0d12aea00 a1a28e7b2b13fe63d4f9442dd54a321f287548fc M etc
:040000 040000 6db42693d65c3b986164cab0545862e24303d346 00945565cec8df9a4cf92806e3485b67c1143f8e M lisp
[-- Attachment #2: m-x bug.png --]
[-- Type: image/png, Size: 21743 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#23002: 25.0.92; sluggish M-x 2016-03-13 4:01 bug#23002: 25.0.92; sluggish M-x Leo Liu @ 2016-03-13 16:03 ` Drew Adams 2016-03-13 16:08 ` Eli Zaretskii 1 sibling, 0 replies; 13+ messages in thread From: Drew Adams @ 2016-03-13 16:03 UTC (permalink / raw) To: 23002 > Don't complete obsolete commands. Not to mention that it is inappropriate not to continue to complete obsolete commands. As long as a feature has only been deprecated (declared "obsolete"), but has not yet been officially desupported, it should (duh) continue to be supported. This is uncalled for, premature desupport. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-13 4:01 bug#23002: 25.0.92; sluggish M-x Leo Liu 2016-03-13 16:03 ` Drew Adams @ 2016-03-13 16:08 ` Eli Zaretskii 2016-03-14 4:21 ` Leo Liu 1 sibling, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2016-03-13 16:08 UTC (permalink / raw) To: Leo Liu; +Cc: 23002, monnier > From: Leo Liu <sdl.web@gmail.com> > Date: Sun, 13 Mar 2016 12:01:56 +0800 > Cc: Stefan Monnier <monnier@iro.umontreal.ca> > > 1. start a NEW GUI Emacs with `emacs -q' and go to the *Scratch* buffer > 2. M-x emacs-lisp-mode RET > > The cursor stays in the minibuffer (see the screenshot; long enough for > me to take a screenshot) for a few seconds before the message "You can > run the command ‘emacs-lisp-mode’ with M-x e-li-mo RET". I cannot reproduce this on my system. (You didn't say which system is yours, nor which commit is was built from, so I cannot compare that.) Here, the cursor exits the minibuffer immediately, and if I type something, the hint message is never shown (as I'd expect). Sounds like sit-for is not working correctly on your system, but I have no idea why that should happen. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-13 16:08 ` Eli Zaretskii @ 2016-03-14 4:21 ` Leo Liu 2016-03-15 8:14 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 13+ messages in thread From: Leo Liu @ 2016-03-14 4:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23002, monnier On 2016-03-13 18:08 +0200, Eli Zaretskii wrote: > I cannot reproduce this on my system. (You didn't say which system is > yours, nor which commit is was built from, so I cannot compare that.) > Here, the cursor exits the minibuffer immediately, and if I type > something, the hint message is never shown (as I'd expect). > > Sounds like sit-for is not working correctly on your system, but I > have no idea why that should happen. At the time of reporting I didn't have access to a NS build. I just did one and couldn't reproduce it either. I have emailed MacPort maintainer to take a look at this bug and will act accordingly. Thanks. Leo ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-14 4:21 ` Leo Liu @ 2016-03-15 8:14 ` YAMAMOTO Mitsuharu 2016-03-15 11:10 ` Leo Liu 2016-03-15 14:21 ` Stefan Monnier 0 siblings, 2 replies; 13+ messages in thread From: YAMAMOTO Mitsuharu @ 2016-03-15 8:14 UTC (permalink / raw) To: Leo Liu; +Cc: 23002, monnier >>>>> On Mon, 14 Mar 2016 12:21:54 +0800, Leo Liu <sdl.web@gmail.com> said: > On 2016-03-13 18:08 +0200, Eli Zaretskii wrote: >> I cannot reproduce this on my system. (You didn't say which system is >> yours, nor which commit is was built from, so I cannot compare that.) >> Here, the cursor exits the minibuffer immediately, and if I type >> something, the hint message is never shown (as I'd expect). >> >> Sounds like sit-for is not working correctly on your system, but I >> have no idea why that should happen. > At the time of reporting I didn't have access to a NS build. I just did > one and couldn't reproduce it either. I have emailed MacPort maintainer > to take a look at this bug and will act accordingly. Thanks. Not updating the display on the Mac port is because it avoids frequent flushes and input reads for overall performance. Flushing is deferred until the next input reading, and in the case that execute-extended-command--shorter takes a long time, it will be at the timing of the next polling (every 2 seconds by default). However, the sluggishness during the evaluation of execute-extended-command--shorter is common to the both ports on OS X, or non-interrupt-driven systems that use polling with SIGALRM for quit/while-no-input handling, in general. I'm thinkng about applying the following patch to the Mac port, but it might also be useful for other systems. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp diff --git a/lisp/simple.el b/lisp/simple.el index 4954763..57b7ca6 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -1642,6 +1642,7 @@ execute-extended-command--shorter (let ((candidates '()) (max (length typed)) (len 1) + (use-polling (and (null (car (current-input-mode))) throw-on-input)) binding) (while (and (not binding) (progn @@ -1652,6 +1653,11 @@ execute-extended-command--shorter ;; Don't show the help message if the binding isn't ;; significantly shorter than the M-x command the user typed. (< len (- max 5)))) + ;; On non-interrupt-driven systems, while-no-input polls for + ;; input every `polling-period' (default 2) seconds, and that is + ;; not frequent enough. So we call input-pending-p manually. + (if (and use-polling (input-pending-p)) + (signal 'quit nil)) (let ((candidate (pop candidates))) (when (equal name (car-safe (completion-try-completion ^ permalink raw reply related [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-15 8:14 ` YAMAMOTO Mitsuharu @ 2016-03-15 11:10 ` Leo Liu 2016-03-15 14:21 ` Stefan Monnier 1 sibling, 0 replies; 13+ messages in thread From: Leo Liu @ 2016-03-15 11:10 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: 23002, monnier On 2016-03-15 17:14 +0900, YAMAMOTO Mitsuharu wrote: > However, the sluggishness during the evaluation of > execute-extended-command--shorter is common to the both ports on OS X, > or non-interrupt-driven systems that use polling with SIGALRM for > quit/while-no-input handling, in general. I'm thinkng about applying > the following patch to the Mac port, but it might also be useful for > other systems. FWIW I can confirm that the patch fixes the bug. Thanks! Leo ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-15 8:14 ` YAMAMOTO Mitsuharu 2016-03-15 11:10 ` Leo Liu @ 2016-03-15 14:21 ` Stefan Monnier 2016-03-15 23:52 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 13+ messages in thread From: Stefan Monnier @ 2016-03-15 14:21 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Leo Liu, 23002 > However, the sluggishness during the evaluation of > execute-extended-command--shorter is common to the both ports on OS X, > or non-interrupt-driven systems that use polling with SIGALRM for > quit/while-no-input handling, in general. I'm thinkng about applying > the following patch to the Mac port, but it might also be useful for > other systems. Hmm... this seems to indicate that while-no-input is just not really working in those systems. > + ;; On non-interrupt-driven systems, while-no-input polls for > + ;; input every `polling-period' (default 2) seconds, and that is > + ;; not frequent enough. So we call input-pending-p manually. > + (if (and use-polling (input-pending-p)) > + (signal 'quit nil)) Hmm... I'm not sure I understand: if input-pending-p returns non-nil, why are we still in this loop? IOW, I get the impression that the above call to input-pending-p will end up triggering a kind of "poll" to fetch new input, so we should be able to arrange for this fetching to trigger whatever should normally be triggered by incoming input (e.g. getting out of the while-no-input loop), so we could just reduce the above 2 lines to a single call to `input-pending-p'. I understand this may not seem like a big progress, but "every bit counts" ;-) tho more seriously, I'm asking this mostly to better understand what's going on (but also because I get the impression that (signal 'quit nil) is not always the right thing to do). Stefan ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-15 14:21 ` Stefan Monnier @ 2016-03-15 23:52 ` YAMAMOTO Mitsuharu 2016-03-16 1:31 ` Stefan Monnier 0 siblings, 1 reply; 13+ messages in thread From: YAMAMOTO Mitsuharu @ 2016-03-15 23:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: 23002, Leo Liu >>>>> On Tue, 15 Mar 2016 10:21:36 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said: >> However, the sluggishness during the evaluation of >> execute-extended-command--shorter is common to the both ports on OS X, >> or non-interrupt-driven systems that use polling with SIGALRM for >> quit/while-no-input handling, in general. I'm thinkng about applying >> the following patch to the Mac port, but it might also be useful for >> other systems. > Hmm... this seems to indicate that while-no-input is just not really > working in those systems. At least, not in a responsive way. I first tried to shorten the polling interval in start_polling if Vthrow_on_input is non-nil. But let-binding throw-on-input as in the definition of while-no-input was not enough and we would need some explicit function call to activate start_polling. >> + ;; On non-interrupt-driven systems, while-no-input polls for >> + ;; input every `polling-period' (default 2) seconds, and that is >> + ;; not frequent enough. So we call input-pending-p manually. >> + (if (and use-polling (input-pending-p)) >> + (signal 'quit nil)) > Hmm... I'm not sure I understand: if input-pending-p returns non-nil, > why are we still in this loop? > IOW, I get the impression that the above call to input-pending-p will > end up triggering a kind of "poll" to fetch new input, so we should be > able to arrange for this fetching to trigger whatever should normally be > triggered by incoming input (e.g. getting out of the while-no-input > loop), so we could just reduce the above 2 lines to a single call to > `input-pending-p'. > I understand this may not seem like a big progress, but "every bit > counts" ;-) tho more seriously, I'm asking this mostly to better > understand what's going on (but also because I get the impression that > (signal 'quit nil) is not always the right thing to do). Indeed. (if use-polling (input-pending-p)) does work. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-15 23:52 ` YAMAMOTO Mitsuharu @ 2016-03-16 1:31 ` Stefan Monnier 2016-03-20 9:10 ` Leo Liu 0 siblings, 1 reply; 13+ messages in thread From: Stefan Monnier @ 2016-03-16 1:31 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Leo Liu, 23002 >> Hmm... this seems to indicate that while-no-input is just not really >> working in those systems. > At least, not in a responsive way. I first tried to shorten the > polling interval in start_polling if Vthrow_on_input is non-nil. But > let-binding throw-on-input as in the definition of while-no-input was > not enough and we would need some explicit function call to activate > start_polling. Hmm... that sucks. We could change while-no-input to call an ad-hoc function after binding throw-on-input, if there's no other solution. > Indeed. (if use-polling (input-pending-p)) does work. So we could define a `poll' function that does just that. It's not ideal either, of course, Stefan ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-16 1:31 ` Stefan Monnier @ 2016-03-20 9:10 ` Leo Liu 2016-12-25 6:48 ` Leo Liu 0 siblings, 1 reply; 13+ messages in thread From: Leo Liu @ 2016-03-20 9:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: 23002 On 2016-03-15 21:31 -0400, Stefan Monnier wrote: > Hmm... that sucks. We could change while-no-input to call an ad-hoc > function after binding throw-on-input, if there's no other solution. > >> Indeed. (if use-polling (input-pending-p)) does work. > > So we could define a `poll' function that does just that. It's not > ideal either, of course How do we proceed from here? I'd like to see this bug fixed for the next pretest. Thanks, Leo ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-03-20 9:10 ` Leo Liu @ 2016-12-25 6:48 ` Leo Liu 2020-09-05 14:08 ` Lars Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Leo Liu @ 2016-12-25 6:48 UTC (permalink / raw) To: 23002 For the record. A workaround is made in emacs 25.2 by introducing a dummy call to (input-pending-p) in execute-extended-command--shorter. A proper fix per Stefan Monnier: Re-reading the thread, the *right* solution is to fix while-no-input, and apparently the easiest way to do that would be to change while-no-input so that it calls an `internal--adjust-polling-frequency` function after binding throw-on-input (and maybe after un-binding it as well). On systems which don't use polling at all, internal--adjust-polling-frequency would just do nothing. The patch should be fairly simple, but I don't think anyone wrote such a patch yet, so I can't tell if it would be appropriate for emacs-25. Maybe for emacs-25 we can live with the workaround of adding a "dummy" call to (input-pending-p) in execute-extended-command--shorter. See also https://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00737.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2016-12-25 6:48 ` Leo Liu @ 2020-09-05 14:08 ` Lars Ingebrigtsen 2020-10-07 3:45 ` Lars Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Lars Ingebrigtsen @ 2020-09-05 14:08 UTC (permalink / raw) To: Leo Liu; +Cc: 23002 Leo Liu <sdl.web@gmail.com> writes: > For the record. > > A workaround is made in emacs 25.2 by introducing a dummy call to > (input-pending-p) in execute-extended-command--shorter. Skimming this bug report, it seems like it only affects the Mac port version of Emacs, and the maintainer of that port mentioned just applying a patch to that port. So I'm not sure whether there's anything further to do in this bug report? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#23002: 25.0.92; sluggish M-x 2020-09-05 14:08 ` Lars Ingebrigtsen @ 2020-10-07 3:45 ` Lars Ingebrigtsen 0 siblings, 0 replies; 13+ messages in thread From: Lars Ingebrigtsen @ 2020-10-07 3:45 UTC (permalink / raw) To: Leo Liu; +Cc: 23002 Lars Ingebrigtsen <larsi@gnus.org> writes: > Skimming this bug report, it seems like it only affects the Mac port > version of Emacs, and the maintainer of that port mentioned just > applying a patch to that port. > > So I'm not sure whether there's anything further to do in this bug > report? This was a month ago, and there was no response, so I'm closing this bug report. If there's anything further to be done here, please send an email to the debbugs address, and we'll reopen. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-10-07 3:45 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-13 4:01 bug#23002: 25.0.92; sluggish M-x Leo Liu 2016-03-13 16:03 ` Drew Adams 2016-03-13 16:08 ` Eli Zaretskii 2016-03-14 4:21 ` Leo Liu 2016-03-15 8:14 ` YAMAMOTO Mitsuharu 2016-03-15 11:10 ` Leo Liu 2016-03-15 14:21 ` Stefan Monnier 2016-03-15 23:52 ` YAMAMOTO Mitsuharu 2016-03-16 1:31 ` Stefan Monnier 2016-03-20 9:10 ` Leo Liu 2016-12-25 6:48 ` Leo Liu 2020-09-05 14:08 ` Lars Ingebrigtsen 2020-10-07 3:45 ` Lars Ingebrigtsen
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).