GNU bug report logs - #38024
27.0.50; icomplete sometimes fails to show completions after backward-killing words

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 38024 in the body.
You can then email your comments to 38024 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: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: João Távora <joaotavora <at> gmail.com>
Subject: 27.0.50; icomplete sometimes fails to show completions after
 backward-killing words
Date: Fri, 01 Nov 2019 22:40:10 +0100

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

Hello,

tl;dr unless I'm mistaken, sometimes `while-no-input' returns t despite
no input having arrived; this prevents `icomplete-exhibit' from
displaying completion candidates.

In more details:

This is a bit of a heisenbug; hopefully someone out there will know what
knobs to tweak to find more information about this.

From emacs -Q:

    M-x icomplete-mode RET
    ;; Find a way to set `default-directory' to some long-ish path,
    ;; e.g. with:
    M-x find-library RET icomplete RET
    C-x C-f
    ;; icomplete should show a bunch of completions.
    M-DEL
    M-DEL
    …

After each `backward-kill-word', icomplete usually displays new
completion candidates with no further user input; sometimes however, no
candidates show up until the user does something (e.g. press TAB or
start typing).

Commit 5860fd3 (Make icomplete-exhibit actually work when navigating up
directories) tried to fix this, but AFAICT it merely reduces the odds of
the bug happening: I can still reproduce it, although less often.  Also,
this new call to `redisplay' causes some noticeable flickering when
typing characters: the completions blink in and out as I fill in the
prompt.

I've tinkered with icomplete.el (commenting out the call to `redisplay'
since it makes the bug harder to trigger); the closest I got to
pin-pointing the cause for this issue was while goofing around in
`icomplete-exhibit', specifically with the `while-no-input' part:

          (let* (…
                 (text (while-no-input
                         (icomplete-completions
                          …)))
                 …)
            ;; Do nothing if while-no-input was aborted.
            (when (stringp text)
              update overlay…))

I replaced (when (stringp text) …) with (if (stringp text) (progn …)
(message "text is %s" text)): it seems that text is t when icomplete
fails to show updated candidates, which according to `while-no-input'
means that some input arrived…

However, when I tried to debug `while-no-input', I got stumped: I tried
to do some more printf-debugging[1], but all I observe is that
sometimes, the code seems to be interrupted between

	 (let ((throw-on-input ',catch-sym)
               val)
and
           (setq val (or (input-pending-p)
	                 (progn ,@body)))

I tried to find where exactly the code gets interrupted, but I could not
get a consistent answer; sometimes it seems to be before executing body,
sometimes it seems to be somewhere inside `icomplete-completions'…

What would be the best way to investigate this further?

Thank you for your time.


[1] With this patch:

[icomplete-debug.patch (text/x-diff, attachment)]

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

When the bug happens, I get the following messages:

    after with-local-quit
    after catch and let
    text is t


PS: It just occured to me that I should search debbugs for
    "while-no-input" in addition to "icomplete".  I just did that;
    bug#15042 looks like it could maybe be related?


In GNU Emacs 27.0.50 (build 6, i686-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
 of 2019-10-21 built on little-buster
Repository revision: 61fb5214816ef3d57e676d900e499ffcd079a1f9
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Configured using:
 'configure --with-xwidgets --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

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

From: João Távora <joaotavora <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 27.0.50; icomplete sometimes fails to show completions after
 backward-killing words
Date: Fri, 1 Nov 2019 23:28:30 +0000

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

Kevin, you're on the right track. The redisplay thing is not the right fix,
indeed. Stefan has a fix for this, which he sent me, but I can't find it
now.

Anyway, it has to do with avoiding the 'select' event in while-no-input.

In case you want to try that before Stefan drops by.

João

On Fri, Nov 1, 2019, 21:40 Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
wrote:

> Hello,
>
> tl;dr unless I'm mistaken, sometimes `while-no-input' returns t despite
> no input having arrived; this prevents `icomplete-exhibit' from
> displaying completion candidates.
>
> In more details:
>
> This is a bit of a heisenbug; hopefully someone out there will know what
> knobs to tweak to find more information about this.
>
> From emacs -Q:
>
>     M-x icomplete-mode RET
>     ;; Find a way to set `default-directory' to some long-ish path,
>     ;; e.g. with:
>     M-x find-library RET icomplete RET
>     C-x C-f
>     ;; icomplete should show a bunch of completions.
>     M-DEL
>     M-DEL
>     …
>
> After each `backward-kill-word', icomplete usually displays new
> completion candidates with no further user input; sometimes however, no
> candidates show up until the user does something (e.g. press TAB or
> start typing).
>
> Commit 5860fd3 (Make icomplete-exhibit actually work when navigating up
> directories) tried to fix this, but AFAICT it merely reduces the odds of
> the bug happening: I can still reproduce it, although less often.  Also,
> this new call to `redisplay' causes some noticeable flickering when
> typing characters: the completions blink in and out as I fill in the
> prompt.
>
> I've tinkered with icomplete.el (commenting out the call to `redisplay'
> since it makes the bug harder to trigger); the closest I got to
> pin-pointing the cause for this issue was while goofing around in
> `icomplete-exhibit', specifically with the `while-no-input' part:
>
>           (let* (…
>                  (text (while-no-input
>                          (icomplete-completions
>                           …)))
>                  …)
>             ;; Do nothing if while-no-input was aborted.
>             (when (stringp text)
>               update overlay…))
>
> I replaced (when (stringp text) …) with (if (stringp text) (progn …)
> (message "text is %s" text)): it seems that text is t when icomplete
> fails to show updated candidates, which according to `while-no-input'
> means that some input arrived…
>
> However, when I tried to debug `while-no-input', I got stumped: I tried
> to do some more printf-debugging[1], but all I observe is that
> sometimes, the code seems to be interrupted between
>
>          (let ((throw-on-input ',catch-sym)
>                val)
> and
>            (setq val (or (input-pending-p)
>                          (progn ,@body)))
>
> I tried to find where exactly the code gets interrupted, but I could not
> get a consistent answer; sometimes it seems to be before executing body,
> sometimes it seems to be somewhere inside `icomplete-completions'…
>
> What would be the best way to investigate this further?
>
> Thank you for your time.
>
>
> [1] With this patch:
>
>
> When the bug happens, I get the following messages:
>
>     after with-local-quit
>     after catch and let
>     text is t
>
>
> PS: It just occured to me that I should search debbugs for
>     "while-no-input" in addition to "icomplete".  I just did that;
>     bug#15042 looks like it could maybe be related?
>
>
> In GNU Emacs 27.0.50 (build 6, i686-pc-linux-gnu, GTK+ Version 3.24.5,
> cairo version 1.16.0)
>  of 2019-10-21 built on little-buster
> Repository revision: 61fb5214816ef3d57e676d900e499ffcd079a1f9
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
> System Description: Debian GNU/Linux 10 (buster)
>
> Configured using:
>  'configure --with-xwidgets --with-cairo'
>
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
> INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
> ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
> LIBSYSTEMD JSON PDUMPER LCMS2 GMP
>
> Important settings:
>   value of $LANG: en_US.UTF-8
>   locale-coding-system: utf-8-unix
>

[Message part 2 (text/html, inline)]

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

From: João Távora <joaotavora <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 38024 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 27.0.50; icomplete sometimes fails to show completions after
 backward-killing words
Date: Sat, 02 Nov 2019 03:05:17 +0000

João Távora <joaotavora <at> gmail.com> writes:

> Kevin, you're on the right track. The redisplay thing is not the right
> fix, indeed. Stefan has a fix for this, which he sent me, but I can't
> find it now.
>
> Anyway, it has to do with avoiding the 'select' event in
> while-no-input.

Hi Kévin,

In the meantime, I found the patch and pushed it right away.  It worked
better than the redisplay hack I had pushed before.

The commit you want to test with is
730e7da7ba6a4b545176ea246653928edb10cff4

Let me know how it works for you,
João

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 38024 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, kevin.legouguec <at> gmail.com
Subject: Re: bug#38024: 27.0.50;
 icomplete sometimes fails to show completions after backward-killing
 words
Date: Sat, 02 Nov 2019 09:37:52 +0200

> From: João Távora <joaotavora <at> gmail.com>
> Date: Sat, 02 Nov 2019 03:05:17 +0000
> Cc: 38024 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
> 
> João Távora <joaotavora <at> gmail.com> writes:
> 
> > Kevin, you're on the right track. The redisplay thing is not the right
> > fix, indeed. Stefan has a fix for this, which he sent me, but I can't
> > find it now.
> >
> > Anyway, it has to do with avoiding the 'select' event in
> > while-no-input.
> 
> Hi Kévin,
> 
> In the meantime, I found the patch and pushed it right away.  It worked
> better than the redisplay hack I had pushed before.
> 
> The commit you want to test with is
> 730e7da7ba6a4b545176ea246653928edb10cff4

The current master displays this warning when byte-compiling
icomplete.el:

    ELC      icomplete.elc

  In end of data:
  icomplete.el:669:1:Warning: the function `while-no-input-ignore-events' is not
      known to be defined.

while-no-input-ignore-events is not a function, it's a variable.

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38024 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, kevin.legouguec <at> gmail.com
Subject: Re: bug#38024: 27.0.50; icomplete sometimes fails to show
 completions after backward-killing words
Date: Sat, 02 Nov 2019 11:12:07 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>   In end of data:
>   icomplete.el:669:1:Warning: the function `while-no-input-ignore-events' is not
>       known to be defined.
>
> while-no-input-ignore-events is not a function, it's a variable.

Sorry,

This was a merge blunder when reordering commits. The reference appears
again in the corrct variable form below.  I've now fixed the problem in
6911ef3da69333cb7adc1a7fb0a0fc001220a0c4.

João

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 38024 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, kevin.legouguec <at> gmail.com
Subject: Re: bug#38024: 27.0.50; icomplete sometimes fails to show
 completions after backward-killing words
Date: Sat, 02 Nov 2019 15:07:26 +0200

> From: João Távora <joaotavora <at> gmail.com>
> Cc: kevin.legouguec <at> gmail.com,  38024 <at> debbugs.gnu.org,
>   monnier <at> iro.umontreal.ca
> Date: Sat, 02 Nov 2019 11:12:07 +0000
> 
> > while-no-input-ignore-events is not a function, it's a variable.
> 
> Sorry,
> 
> This was a merge blunder when reordering commits. The reference appears
> again in the corrct variable form below.  I've now fixed the problem in
> 6911ef3da69333cb7adc1a7fb0a0fc001220a0c4.

Thanks, compiles cleanly now.

Message #25 received at 38024-done <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38024-done <at> debbugs.gnu.org,
 João Távora <joaotavora <at> gmail.com>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#38024: 27.0.50; icomplete sometimes fails to show
 completions after backward-killing words
Date: Sun, 03 Nov 2019 11:25:49 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, compiles cleanly now.

And AFAICT, everything's fine now!  (Completions show up no matter how
many M-DELs I hit; no more flickering when typing.)

Thank you all for working on this; closing (if I'm reading
admin/notes/bugtracker correctly).

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Eli Zaretskii <eliz <at> gnu.org>,
 38024 <at> debbugs.gnu.org, kevin.legouguec <at> gmail.com
Subject: Re: bug#38024: 27.0.50; icomplete sometimes fails to show
 completions after backward-killing words
Date: Mon, 05 Apr 2021 16:59:32 -0400

[ Resending, as usual, since the bug was archived.  Sorry.  ]

João Távora [2019-11-02 11:12:07] wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>>   In end of data:
>>   icomplete.el:669:1:Warning: the function `while-no-input-ignore-events' is not
>>       known to be defined.
>> while-no-input-ignore-events is not a function, it's a variable.
> Sorry,
> This was a merge blunder when reordering commits. The reference appears
> again in the corrct variable form below.  I've now fixed the problem in
> 6911ef3da69333cb7adc1a7fb0a0fc001220a0c4.

Hmm... so the patch installed was basically:

    commit 88f193ed05649b8c622867b8b2623b8cb08fdc96
    Author: João Távora <joaotavora <at> gmail.com>
    Date:   Sat Nov 2 02:29:56 2019 +0000
    
        Improve fix for icomplete's backward-kill-word bug#38024
        
        * lisp/icomplete.el (icomplete-exhibit): Use
        while-no-input-ignore-events, not redisplay.
        
        Co-authored-by: Stefan Monnier <j.schmoe <at> example.org>
    
    diff --git a/lisp/icomplete.el b/lisp/icomplete.el
    index 02eae55a19..89318ca4c7 100644
    --- a/lisp/icomplete.el
    +++ b/lisp/icomplete.el
    @@ -399,8 +399,6 @@ icomplete-exhibit
     See `icomplete-mode' and `minibuffer-setup-hook'."
       (when (and icomplete-mode
                  (icomplete-simple-completing-p)) ;Shouldn't be necessary.
    -    (redisplay)     ; FIXME: why is this sometimes needed when moving
    -                    ; up dirs in a file-finding table?
         (save-excursion
           (goto-char (point-max))
                                             ; Insert the match-status information:
    @@ -420,6 +418,11 @@ icomplete-exhibit
                    ;; embarking on computing completions:
                    (sit-for icomplete-compute-delay)))
              (let* ((field-string (icomplete--field-string))
    +                 ;; Not sure why, but such requests seem to come
    +                 ;; every once in a while.  It's not fully
    +                 ;; deterministic but `C-x C-f M-DEL M-DEL ...'
    +                 ;; seems to trigger it fairly often!
    +                 (while-no-input-ignore-events '(selection-request))
                      (text (while-no-input
                              (icomplete-completions
                               field-string

but I don't understand why that would help and/or be needed:
`selection-request` is (and has been for many years) in the default
value of `while-no-input-ignore-events` (as set in `subr.el`), so what
this patch ends up doing is forcing `while-no-input` to exit with value
t in more cases (i.e. whenever one of the events in (focus-in focus-out
help-echo iconify-frame make-frame-visible) comes in) rather than
the opposite.

What am I missing?


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: mail <at> daniel-mendler.de, 38024 <at> debbugs.gnu.org, joaotavora <at> gmail.com,
 kevin.legouguec <at> gmail.com
Subject: Re: Remove icomplete workaround
Date: Sun, 31 Oct 2021 22:38:45 -0400

Aaron Jensen [2021-10-31 20:49:23] wrote:
> Originally added because of: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38024
>
> The reason this fixed things was not captured and I can not reproduce
> the bug with the fix disabled on master.
>
> This workaround has been copied to other libraries without clear
> understanding of why it existed in the first place and it caused a
> problem: https://github.com/minad/vertico/issues/115#issuecomment-947330581
>
> Would it be possible to remove it? I'm ccing the original reporter and
> fixer in case they are able to shed more light on this or test without
> the fix to see if they can reproduce it.
>
> I've attached a patch if we are good to remove it.

Thanks, I just pushed your patch to `master`.
We'll see if the problem comes back, and if so, we'll have to try and
fix it better.


        Stefan

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: mail <at> daniel-mendler.de, 38024 <at> debbugs.gnu.org, joaotavora <at> gmail.com,
 kevin.legouguec <at> gmail.com
Subject: Re: Remove icomplete workaround
Date: Sun, 31 Oct 2021 23:55:49 -0400

On Sun, Oct 31, 2021 at 10:38 PM Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>
> Aaron Jensen [2021-10-31 20:49:23] wrote:
> > Originally added because of: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38024
> >
> > The reason this fixed things was not captured and I can not reproduce
> > the bug with the fix disabled on master.
> >
> > This workaround has been copied to other libraries without clear
> > understanding of why it existed in the first place and it caused a
> > problem: https://github.com/minad/vertico/issues/115#issuecomment-947330581
> >
> > Would it be possible to remove it? I'm ccing the original reporter and
> > fixer in case they are able to shed more light on this or test without
> > the fix to see if they can reproduce it.
> >
> > I've attached a patch if we are good to remove it.
>
> Thanks, I just pushed your patch to `master`.
> We'll see if the problem comes back, and if so, we'll have to try and
> fix it better.

Great, thank you!

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: mail <at> daniel-mendler.de, 38024 <at> debbugs.gnu.org, joaotavora <at> gmail.com,
 Aaron Jensen <aaronjensen <at> gmail.com>
Subject: Re: Remove icomplete workaround
Date: Mon, 01 Nov 2021 10:28:40 +0100

Hey Aaron,

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Aaron Jensen [2021-10-31 20:49:23] wrote:
>>
>> Would it be possible to remove it? I'm ccing the original reporter and
>> fixer in case they are able to shed more light on this or test without
>> the fix to see if they can reproduce it.
>>
>> I've attached a patch if we are good to remove it.
>
> Thanks, I just pushed your patch to `master`.
> We'll see if the problem comes back, and if so, we'll have to try and
> fix it better.

Congrats on your investigation work; I wish I could shed more light on
what this workaround was meant to accomplish.  I've tried to reproduce
my original issue, but so far I was not successful.

If my initial report can be trusted, the bug happened (1) back when the
development branch was 27.0.50 (commit 61fb521481) (2) on an old
battered laptop that I can no longer power on without disturbing loud
fan demons.

26.3 no longer compiles on my end[1], so all I could do was try to
reproduce on master, where the workaround has been reverted, on other
computers I have lying around.  The symptoms have not resurfaced yet,
so… I'll go with a timid, yet hopeful "yay" 🙂


[1] With gcc 11.2.1:
sysdep.c:1795:22: error: variably modified ‘sigsegv_stack’ at file scope
 1795 | static unsigned char sigsegv_stack[SIGSTKSZ];
      |                      ^~~~~~~~~~~~~

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: mail <at> daniel-mendler.de, 38024 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, joaotavora <at> gmail.com
Subject: Re: Remove icomplete workaround
Date: Mon, 1 Nov 2021 11:33:44 -0400

On Mon, Nov 1, 2021 at 5:28 AM Kévin Le Gouguec
<kevin.legouguec <at> gmail.com> wrote:
>
> Hey Aaron,
>
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> > Aaron Jensen [2021-10-31 20:49:23] wrote:
> >>
> >> Would it be possible to remove it? I'm ccing the original reporter and
> >> fixer in case they are able to shed more light on this or test without
> >> the fix to see if they can reproduce it.
> >>
> >> I've attached a patch if we are good to remove it.
> >
> > Thanks, I just pushed your patch to `master`.
> > We'll see if the problem comes back, and if so, we'll have to try and
> > fix it better.
>
> Congrats on your investigation work; I wish I could shed more light on
> what this workaround was meant to accomplish.  I've tried to reproduce
> my original issue, but so far I was not successful.
>
> If my initial report can be trusted, the bug happened (1) back when the
> development branch was 27.0.50 (commit 61fb521481) (2) on an old
> battered laptop that I can no longer power on without disturbing loud
> fan demons.
>
> 26.3 no longer compiles on my end[1], so all I could do was try to
> reproduce on master, where the workaround has been reverted, on other
> computers I have lying around.  The symptoms have not resurfaced yet,
> so… I'll go with a timid, yet hopeful "yay" 🙂

Thank you for confirming. Hopefully that's the last of it!

Best,

Aaron

Previous Next

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