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