bug#23002: 25.0.92; sluggish M-x

bug#23002: 25.0.92; sluggish M-x

[Leo Liu]

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

bug#23002: 25.0.92; sluggish M-x

[Drew Adams]

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

bug#23002: 25.0.92; sluggish M-x

[Eli Zaretskii]

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

bug#23002: 25.0.92; sluggish M-x

[Leo Liu]

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

bug#23002: 25.0.92; sluggish M-x

[YAMAMOTO Mitsuharu]

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

bug#23002: 25.0.92; sluggish M-x

[Leo Liu]

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

bug#23002: 25.0.92; sluggish M-x

[Stefan Monnier]

> 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

bug#23002: 25.0.92; sluggish M-x

[YAMAMOTO Mitsuharu]

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

bug#23002: 25.0.92; sluggish M-x

[Stefan Monnier]

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

bug#23002: 25.0.92; sluggish M-x

[Leo Liu]

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

bug#23002: 25.0.92; sluggish M-x

[Leo Liu]

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

bug#23002: 25.0.92; sluggish M-x

[Lars Ingebrigtsen]

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

bug#23002: 25.0.92; sluggish M-x

[Lars Ingebrigtsen]

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