GNU bug report logs - #40152
27.0.90; icomplete vs recursive prompts

Previous Next

To reply to this bug, email your comments to 40152 AT debbugs.gnu.org.

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
Subject: 27.0.90; icomplete vs recursive prompts
Date: Fri, 20 Mar 2020 19:21:01 +0100

Hello,

There seems to be some interference between icomplete-mode and some
prompting functions such as xref-find-definitions.  From emacs -Q, after
M-x icomplete-mode:

- "Synthetic" reproduction recipe:
    - (completing-read "Foo? " (tags-lazy-completion-table))

- With actual user commands:
    - C-x b foo RET
      - or any non-Lisp buffer, so that xref picks the etags backend
    - M-.

From there:

- Try to input a character.
    - The identifier prompt is interrupted by the etags prompt ("Visit
      tags table").
- Try to input a character.
    - The etags prompt disappears and we're back to the identifier
      prompt.

The identifier prompt is replaced with the etags prompt as soon as a
single character is typed.  While in the etags prompt, one can use
icomplete commands (e.g. TAB, C-.) as well as C-q CHAR to input
characters one-by-one.

This seems to be reproducible as far back as version 25.3 (couldn't get
any 24.x version to compile).

(ISTR another instance of this bug where TRAMP and EPG would fight each
other when using the sudo or sudoedit methods (the former asking for the
root password, the latter for the ~/.authinfo.gpg key), but I can't seem
to reproduce it.)


Let me know if this report needs more details.  Thank you for your time.


In GNU Emacs 28.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.24.14, cairo version 1.16.0)
 of 2020-03-18 built on my-little-tumbleweed
Repository revision: 64d9b4cd762cd39749b899343cb4878e5998a170
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12007000
System Description: openSUSE Tumbleweed

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 JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 40152 <at> debbugs.gnu.org
Subject: Re: bug#40152: 27.0.90; icomplete vs recursive prompts
Date: Sat, 21 Mar 2020 09:27:44 +0200

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Fri, 20 Mar 2020 19:21:01 +0100
> 
> - "Synthetic" reproduction recipe:
>     - (completing-read "Foo? " (tags-lazy-completion-table))
> 
> - With actual user commands:
>     - C-x b foo RET
>       - or any non-Lisp buffer, so that xref picks the etags backend
>     - M-.
> 
> >From there:
> 
> - Try to input a character.
>     - The identifier prompt is interrupted by the etags prompt ("Visit
>       tags table").
> - Try to input a character.
>     - The etags prompt disappears and we're back to the identifier
>       prompt.
> 
> The identifier prompt is replaced with the etags prompt as soon as a
> single character is typed.  While in the etags prompt, one can use
> icomplete commands (e.g. TAB, C-.) as well as C-q CHAR to input
> characters one-by-one.

What would you like to happen instead?

Message #11 received at 40152 <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: 40152 <at> debbugs.gnu.org
Subject: Re: bug#40152: 27.0.90; icomplete vs recursive prompts
Date: Sat, 21 Mar 2020 13:21:27 +0100

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

>> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
>> Date: Fri, 20 Mar 2020 19:21:01 +0100
>> 
>> - "Synthetic" reproduction recipe:
>>     - (completing-read "Foo? " (tags-lazy-completion-table))
>> 
>> - With actual user commands:
>>     - C-x b foo RET
>>       - or any non-Lisp buffer, so that xref picks the etags backend
>>     - M-.
>> 
>> From there:
>> 
>> - Try to input a character.
>>     - The identifier prompt is interrupted by the etags prompt ("Visit
>>       tags table").
>> - Try to input a character.
>>     - The etags prompt disappears and we're back to the identifier
>>       prompt.
>> 
>> The identifier prompt is replaced with the etags prompt as soon as a
>> single character is typed.  While in the etags prompt, one can use
>> icomplete commands (e.g. TAB, C-.) as well as C-q CHAR to input
>> characters one-by-one.
>
> What would you like to happen instead?

When the etags prompt interrupts the xref prompt, I'd like the etags
prompt to remain uninterrupted until I exit it (with e.g. RET/C-j).  In
particular, self-inserting characters do not cause the xref prompt to
come back.

For example, if I'm in a buffer whose default-directory is the root of
the Emacs source repository (e.g. in a Dired buffer, visiting the
Makefile…) and I hit C-. (and point is not on something that looks like
an identifier), here's what happens:

1. the "Find definitions of" prompt appears,
2. I start typing an identifier,
3. the "Visit tags table" prompt interrupts,
4. I'd like to input "src/ C-j", but every self-inserting character
   makes the prompt go back-and-forth between "Find definitions of" and
   "Visit tags table".  Worse, when the prompt comes back to "Visit tags
   table", any character I had previously input has disappeared.

I just found out that there is a workaround: in step 2, if I hit TAB
(minibuffer-complete) instead of typing an identifier, the "Visit tags
table" prompt comes up *and stays until I exit it*.  The back-and-forth
only starts if

1. I input a self-inserting char during the first prompt, or
2. if icomplete-show-matches-on-no-input is t.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 40152 <at> debbugs.gnu.org
Subject: Re: bug#40152: 27.0.90; icomplete vs recursive prompts
Date: Sat, 21 Mar 2020 15:36:35 +0200

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: 40152 <at> debbugs.gnu.org
> Date: Sat, 21 Mar 2020 13:21:27 +0100
> 
> >> The identifier prompt is replaced with the etags prompt as soon as a
> >> single character is typed.  While in the etags prompt, one can use
> >> icomplete commands (e.g. TAB, C-.) as well as C-q CHAR to input
> >> characters one-by-one.
> >
> > What would you like to happen instead?
> 
> When the etags prompt interrupts the xref prompt, I'd like the etags
> prompt to remain uninterrupted until I exit it (with e.g. RET/C-j).  In
> particular, self-inserting characters do not cause the xref prompt to
> come back.
> 
> For example, if I'm in a buffer whose default-directory is the root of
> the Emacs source repository (e.g. in a Dired buffer, visiting the
> Makefile…) and I hit C-.

You mean, M-., right?

>(and point is not on something that looks like an identifier),

How do you do that?  If I type M-. in *scratch*, Emacs doesn't ask me
whether to visit a tags table (because the major mode is emacs-lisp).
I need to visit a C file in src/ or lib-src/, but then all I need to
type at the prompt is RET, nothing else.  And if I do the above from a
Dired buffer which shows the Emacs's root directory, then I get the
prompt about visiting the tags table without any "Find definitions"
prompt, and the problem doesn't happen.

So please show the exact recipe for how to reproduce the problem you
see.

> here's what happens:
> 
> 1. the "Find definitions of" prompt appears,
> 2. I start typing an identifier,
> 3. the "Visit tags table" prompt interrupts,
> 4. I'd like to input "src/ C-j", but every self-inserting character
>    makes the prompt go back-and-forth between "Find definitions of" and
>    "Visit tags table".  Worse, when the prompt comes back to "Visit tags
>    table", any character I had previously input has disappeared.

So the problem happens _after_ the prompt, not _with_ the prompt.
That wasn't quite clear, at least to me, from your original report:
there was no sign in it what was the actual problem and what was the
expected and result.  Now I think it's becoming clearer, thanks.

Message #17 received at 40152 <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: 40152 <at> debbugs.gnu.org
Subject: Re: bug#40152: 27.0.90; icomplete vs recursive prompts
Date: Sat, 21 Mar 2020 21:03:39 +0100

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

>> For example, if I'm in a buffer whose default-directory is the root of
>> the Emacs source repository (e.g. in a Dired buffer, visiting the
>> Makefile…) and I hit C-.
>
> You mean, M-., right?

Right 🤦.

>>(and point is not on something that looks like an identifier),
>
> How do you do that?  If I type M-. in *scratch*, Emacs doesn't ask me
> whether to visit a tags table (because the major mode is emacs-lisp).
> I need to visit a C file in src/ or lib-src/, but then all I need to
> type at the prompt is RET, nothing else.  And if I do the above from a
> Dired buffer which shows the Emacs's root directory, then I get the
> prompt about visiting the tags table without any "Find definitions"
> prompt, and the problem doesn't happen.
>
> So please show the exact recipe for how to reproduce the problem you
> see.
>
>> here's what happens:
>> 
>> 1. the "Find definitions of" prompt appears,
>> 2. I start typing an identifier,
>> 3. the "Visit tags table" prompt interrupts,
>> 4. I'd like to input "src/ C-j", but every self-inserting character
>>    makes the prompt go back-and-forth between "Find definitions of" and
>>    "Visit tags table".  Worse, when the prompt comes back to "Visit tags
>>    table", any character I had previously input has disappeared.
>
> So the problem happens _after_ the prompt, not _with_ the prompt.
> That wasn't quite clear, at least to me, from your original report:
> there was no sign in it what was the actual problem and what was the
> expected and result.  Now I think it's becoming clearer, thanks.

My apologies for being unclear.  Do those 4 steps you quoted (preceded
by M-x icomplete-mode) demonstrate the problem well enough then, or is
there anything I should add?

To recap:

- The problem only happens
    - with icomplete-mode,
    - with the etags backend,
    - when there is no "identifier-like" symbol under point,
    - when either
        - the user starts typing self-inserting characters when the xref
          identifier prompt shows up, or
        - icomplete-show-matches-on-no-input is t.

- The problem is that one cannot fill in the tags table prompt easily:
  self-inserting characters cause the minibuffer to move back-and-forth
  between the tags table prompt and the xref identifier prompt.

  The tags table prompt interrupting the xref prompt is not an issue (to
  me, at least); what I would like is being able to complete the tags
  table prompt, then go back to the xref prompt.

- A workaround consists in calling minibuffer-complete (TAB) immediately
  when the xref prompt shows up; this brings up a functional tags table
  prompt.
  (This workaround cannot work when icomplete-show-matches-on-no-input
  is t.)

Let me know if I managed to muddy things up further.

Thank you for your patience.

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 40152 <at> debbugs.gnu.org
Subject: Re: bug#40152: 27.0.90; icomplete vs recursive prompts
Date: Mon, 07 Sep 2020 11:11:27 +0200

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> (ISTR another instance of this bug where TRAMP and EPG would fight each
> other when using the sudo or sudoedit methods (the former asking for the
> root password, the latter for the ~/.authinfo.gpg key), but I can't seem
> to reproduce it.)

Found a recipe, with the SSH method:

1. create an ~/.authinfo.gpg file with the EasyPG assistant[1]
2. pkill -HUP gpg-agent
2. emacs -Q
3. (progn
     (setq epg-pinentry-mode 'loopback)
     (icomplete-mode))
5. C-x C-f /ssh:

This brings up epa.el's "Passphrase for symmetric encryption" prompt to
unlock ~/.authinfo.gpg.  The prompt cannot be completed, because any
self-inserting character brings the "Find file" prompt back up, and from
*there*, typing any character brings the "Passphrase for symmetric
encryption" prompt back again.

I don't mind icomplete proactively trying to open authinfo.gpg to
find candidates for hostnames[2]; unfortunately as things stand I have
to hit C-g a bunch, disable icomplete, do whatever I was trying to do,
then enable icomplete back.


[1] I.e. visit ~/.authinfo.gpg, and save it with a password when
    prompted.  The content doesn't matter, but it has to be properly
    encrypted, otherwise GPG will recognize the file is malformed and
    abort before EPA can prompt for a password.

[2] Or a TAGS file to find candidates for identifiers, as seen in the
    initial report.

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 40152 <at> debbugs.gnu.org
Subject: Re: bug#40152: 27.0.90; icomplete vs recursive prompts
Date: Sun, 24 Jan 2021 16:06:55 +0100

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

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> 1. create an ~/.authinfo.gpg file with the EasyPG assistant[1]
> 2. pkill -HUP gpg-agent
> 2. emacs -Q
> 3. (progn
>      (setq epg-pinentry-mode 'loopback)
>      (icomplete-mode))
> 5. C-x C-f /ssh:
>
> This brings up epa.el's "Passphrase for symmetric encryption" prompt to
> unlock ~/.authinfo.gpg.  The prompt cannot be completed, because any
> self-inserting character brings the "Find file" prompt back up, and from
> *there*, typing any character brings the "Passphrase for symmetric
> encryption" prompt back again.

Still getting bitten by this, just about every time I start Emacs and
open a remote file.

I've tried to debug this repeatedly, but I'm obviously doing it wrong
since no amount of debugging-on-entry or tweaking
{pre,post}-command-hook amounted to anything.

FWIW I've dumped backtraces of both the TRAMP recipe and the etags
recipe.

[tramp (text/plain, attachment)]

[etags (text/plain, attachment)]

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

I am mildly intrigued by this comment in icomplete-post-command-hook:

  (defun icomplete-post-command-hook ()
    (let ((non-essential t)) ;E.g. don't prompt for password!
      (icomplete-exhibit)))

As can be seen in the backtraces, prompts are definitely happening while
calling icomplete-exhibit; I have no idea whether this is suspicious, or
if that comment is a red herring…

My hunch is that icomplete sets up *something* that is not cleared and
keeps being triggered when the second prompt shows up; I haven't been
able to pinpoint what yet.

If any completion wizard out here has advice on how to debug this
further, I'm all ears!

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 40152 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: 27.0.90; icomplete vs recursive prompts
Date: Thu, 04 Feb 2021 19:39:41 +0100

OK, I think I have a simpler reproducer.

From emacs -Q:

#+begin_src elisp
(icomplete-mode)
(setq enable-recursive-minibuffers t)
(completing-read
 "Prompt #1? "
 (lambda (&rest _args)
   (read-string "Prompt #2? ")
   (list "foo" "bar" "baz")))
#+end_src

Current result:
1. prompt #1 appears,
2. I type in a letter, say "x",
3. prompt #2 immediately appears, hijacking prompt #1,
4. I type in another letter, say "y",
5. prompt #1 returns, hijacking prompt #2; the "x" I typed is there,
6. I type in another letter, say "z",
7. prompt #2 returns, hijacking prompt #1; the "y" I typed is not there.

Expected result:
1. prompt #1 appears,
2. I type in a letter, say "x",
3. prompt #2 immediately appears, hijacking prompt #1,
4. I type in another letter, say "y",
5. *PROMPT #2 REMAINS* until I hit RET/C-j/C-g…
6. prompt #1 returns; the "x" I typed is there.

(If icomplete-show-matches-on-no-input is set, I guess I'd expect Emacs
to go straight to step 3, with prompt #1 empty on step 6.)

To summarize my previous messages:

- In addition to this synthetic recipe, I have two fairly annoying
  reproducers:

    1. xref-find-definitions bounces back between the identifier prompt
       and the TAGS table prompt (when there are no tags at point and
       xref falls back to the etags backend).

    2. TRAMP bounces back between the filename prompt and the
       .authinfo.gpg passphrase prompt.

- Even after hours of debugging, I still feel out of my depth with the
  completion code; I'd really appreciate some help.  I don't mind
  debugging some more, but at this point I'd need a clue where to look.

(Since I feel like my synthetic reproducer is small enough, I'm boldly
CC'ing folks I imagine to be the most familiar with the completion
framework and/or icomplete; I apologize for the forwardness.)

Message #29 received at 40152 <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: 40152 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#40152: 27.0.90; icomplete vs recursive prompts
Date: Thu, 19 Aug 2021 23:05:51 +0100

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

Sorry Kévin, for having mostly ignored this back in February somehow. I'm
back on the icomplete subject for a while, maybe I'll can look at this. I
think I understand the problem from you clear recipes.

João

On Thu, Feb 4, 2021, 19:20 Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
wrote:

> OK, I think I have a simpler reproducer.
>
> From emacs -Q:
>
> #+begin_src elisp
> (icomplete-mode)
> (setq enable-recursive-minibuffers t)
> (completing-read
>  "Prompt #1? "
>  (lambda (&rest _args)
>    (read-string "Prompt #2? ")
>    (list "foo" "bar" "baz")))
> #+end_src
>
> Current result:
> 1. prompt #1 appears,
> 2. I type in a letter, say "x",
> 3. prompt #2 immediately appears, hijacking prompt #1,
> 4. I type in another letter, say "y",
> 5. prompt #1 returns, hijacking prompt #2; the "x" I typed is there,
> 6. I type in another letter, say "z",
> 7. prompt #2 returns, hijacking prompt #1; the "y" I typed is not there.
>
> Expected result:
> 1. prompt #1 appears,
> 2. I type in a letter, say "x",
> 3. prompt #2 immediately appears, hijacking prompt #1,
> 4. I type in another letter, say "y",
> 5. *PROMPT #2 REMAINS* until I hit RET/C-j/C-g…
> 6. prompt #1 returns; the "x" I typed is there.
>
> (If icomplete-show-matches-on-no-input is set, I guess I'd expect Emacs
> to go straight to step 3, with prompt #1 empty on step 6.)
>
> To summarize my previous messages:
>
> - In addition to this synthetic recipe, I have two fairly annoying
>   reproducers:
>
>     1. xref-find-definitions bounces back between the identifier prompt
>        and the TAGS table prompt (when there are no tags at point and
>        xref falls back to the etags backend).
>
>     2. TRAMP bounces back between the filename prompt and the
>        .authinfo.gpg passphrase prompt.
>
> - Even after hours of debugging, I still feel out of my depth with the
>   completion code; I'd really appreciate some help.  I don't mind
>   debugging some more, but at this point I'd need a clue where to look.
>
> (Since I feel like my synthetic reproducer is small enough, I'm boldly
> CC'ing folks I imagine to be the most familiar with the completion
> framework and/or icomplete; I apologize for the forwardness.)
>
>
>
>

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

Previous Next

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