GNU bug report logs - #23002
[OSX] 25.0.92; sluggish M-x (`while-no-input' non-responsive)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23002 in the body.
You can then email your comments to 23002 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.92; sluggish M-x
Date: Sun, 13 Mar 2016 12:01:56 +0800

[Message part 1 (text/plain, inline)]

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

[m-x bug.png (image/png, attachment)]

Message #8 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 23002 <at> debbugs.gnu.org
Subject: RE: bug#23002: 25.0.92; sluggish M-x
Date: Sun, 13 Mar 2016 09:03:17 -0700 (PDT)

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

Message #11 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 23002 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Sun, 13 Mar 2016 18:08:25 +0200

> From: Leo Liu <sdl.web <at> gmail.com>
> Date: Sun, 13 Mar 2016 12:01:56 +0800
> Cc: Stefan Monnier <monnier <at> 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.

Message #14 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23002 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Mon, 14 Mar 2016 12:21:54 +0800

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

Message #17 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23002 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Tue, 15 Mar 2016 17:14:46 +0900

>>>>> On Mon, 14 Mar 2016 12:21:54 +0800, Leo Liu <sdl.web <at> 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 <at> 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

Message #20 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 23002 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Tue, 15 Mar 2016 19:10:15 +0800

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

Message #23 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Leo Liu <sdl.web <at> gmail.com>,
 23002 <at> debbugs.gnu.org
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Tue, 15 Mar 2016 10:21:36 -0400

> 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

Message #26 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 23002 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Leo Liu <sdl.web <at> gmail.com>,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Wed, 16 Mar 2016 08:52:11 +0900

>>>>> On Tue, 15 Mar 2016 10:21:36 -0400, Stefan Monnier <monnier <at> 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 <at> math.s.chiba-u.ac.jp

Message #29 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Leo Liu <sdl.web <at> gmail.com>,
 23002 <at> debbugs.gnu.org
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Tue, 15 Mar 2016 21:31:04 -0400

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

Message #32 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 23002 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Sun, 20 Mar 2016 17:10:42 +0800

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

Message #37 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: 23002 <at> debbugs.gnu.org
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Sun, 25 Dec 2016 14:48:34 +0800

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

Message #40 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 23002 <at> debbugs.gnu.org
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Sat, 05 Sep 2020 16:08:32 +0200

Leo Liu <sdl.web <at> 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

Message #43 received at 23002 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 23002 <at> debbugs.gnu.org
Subject: Re: bug#23002: 25.0.92; sluggish M-x
Date: Wed, 07 Oct 2020 05:45:19 +0200

Lars Ingebrigtsen <larsi <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.