Debugging a seldom seen bug (C-g with Ido)

Debugging a seldom seen bug (C-g with Ido)

[Vasilii Kolobkov]

Hello Emacs fellows!

I've been living with a minor nuisance of a bug for a long time with
little success in finding the root cause and thought maybe it's time to
solicit some hints from you!

I'm using Ido for all my completion needs, and occasionally when i'm
trying to abort an active ido-find-file command with C-g, i'm getting
"[Quit]" appended to the minibuffer, rather than the operation being
aborted.  As if the keyboard-quit was processed while some buffer other
than minibuffer was current.

It happens rather rarely and i failed to reliably reproduce it following
the script from view-lossage.  But still often enough to occur during a
dedicated session, so that some sort of complete execution trace of a
process to be feasible.

I'd be very much grateful for any ideas on how to pinpoint such a
critter.

Re: Debugging a seldom seen bug (C-g with Ido)

[Stefan Monnier via Users list for the GNU Emacs text editor]

> I'm using Ido for all my completion needs, and occasionally when i'm
> trying to abort an active ido-find-file command with C-g, i'm getting
> "[Quit]" appended to the minibuffer, rather than the operation being
> aborted.  As if the keyboard-quit was processed while some buffer other
> than minibuffer was current.
>
> It happens rather rarely and i failed to reliably reproduce it following
> the script from view-lossage.

It's probably timing-dependent.  My guess is that it happens when you it
`C-g` while Emacs is running some ELisp code and it processes the `C-g` as
a (signal 'quit), like what happens when you hit `C-g` to interrupt
execution of ELisp code, rather than by looking it up in the keymaps.

You can try and debug this with (setq debug-on-error t debug-on-quit t)

This setting can be rather annoying, tho (it will bring up a debugger
buffer every time you interrupt ELisp execution with `C-g`), but if you
hit the problem often enough it might be sufficient to catch the bugger
red-handed.

Feel free to send the resulting backtrace here (along with
a description of what you were doing and what you remember seeing on
screen shortly before the problem).


        Stefan

Re: Debugging a seldom seen bug (C-g with Ido)

[Vasilii Kolobkov]

NB: Resending to the list.

Stefan, thank you so much!

Although i skimmed though the [[info:elisp#Quitting]], i'm still
confused about some parts and might be naming things wrong.

Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> It's probably timing-dependent.  My guess is that it happens when you it
> `C-g` while Emacs is running some ELisp code and it processes the `C-g` as
> a (signal 'quit), like what happens when you hit `C-g` to interrupt
> execution of ELisp code, rather than by looking it up in the keymaps.

This seem to explain it.

> Feel free to send the resulting backtrace here (along with
> a description of what you were doing and what you remember seeing on
> screen shortly before the problem).

I managed to reliably reproduce it now: calling describe-function with
icomplete-mode enabled takes plenty time to produce a list of completion
candidates.

Now if i hit C-g before the candidates are shown, i'm seeing a "[Quit]"
appended to the minibuffer, without other effects, and after a while,
i'd get a list of candidates.  When doing it with debug-on-quit set, i
see just one other redisplay_internal call at the top most of the time.

  Debugger entered--Lisp error: (quit)
    redisplay_internal\ \(C\ function\)()
    read-from-minibuffer("Describe function: " ...)
    completing-read-default("Describe function: " ...)
    completing-read("Describe function: " ...)
    byte-code(...)
    call-interactively(describe-function nil nil)
    command-execute(describe-function)

When the candidates are already  present, hitting C-g aborts out of
minibuffer.  In case of debug-on-quit, it happens here:

  Debugger entered--Lisp error: (quit)
    read-from-minibuffer("Describe function: " ...)
    completing-read-default("Describe function: " ...)
    completing-read("Describe function: " ...)
    byte-code(...)
    call-interactively(describe-function nil nil)
    command-execute(describe-function)

I don't think there is anything wrong here, other than my flawed
expectations :)

Re: Debugging a seldom seen bug (C-g with Ido)

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Now if i hit C-g before the candidates are shown, i'm seeing a "[Quit]"
> appended to the minibuffer, without other effects, and after a while,
> i'd get a list of candidates.  When doing it with debug-on-quit set, i
> see just one other redisplay_internal call at the top most of the time.
>
>   Debugger entered--Lisp error: (quit)
>     redisplay_internal\ \(C\ function\)()
>     read-from-minibuffer("Describe function: " ...)
>     completing-read-default("Describe function: " ...)
>     completing-read("Describe function: " ...)
>     byte-code(...)
>     call-interactively(describe-function nil nil)
>     command-execute(describe-function)

Hmm... yeah, that's not very helpful.

> I don't think there is anything wrong here, other than my flawed
> expectations :)

It is a somewhat delicate part of `C-g`, and whether it's a bug or not
might be debatable, but I think it's clearly an undesirable behavior: it
may be hard to change the code to behave better (I don't know), but it
qualifies for a bug report if you ask me.

It'd be even better if you can reproduce it with a completion package
that's better maintained than Ido (e.g. Icomplete, Mct, Ivy, ...).


        Stefan

Re: Debugging a seldom seen bug (C-g with Ido)

[Vasilii Kolobkov]

Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> It'd be even better if you can reproduce it with a completion package
> that's better maintained than Ido (e.g. Icomplete, Mct, Ivy, ...).

The scenario i mentioned last, using describe-function, does in fact use
Icomplete.  I'd need to ponder over the behavior of 'quiting' first, as
it seem to fit the prescribed behavior at first glance.

On a side note, having compared the length of Ido source code with that
of Icomplete (5 kslocs and <1 ksloc), made me thinking if i can switch
over to icomplete... completely :)