GNU bug report logs - #62468
30.0.50; Improve Icomplete while-no-input s.t. C-g quits the minibuffer

Previous Next

To reply to this bug, email your comments to 62468 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: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Improve Icomplete while-no-input s.t. C-g quits the
 minibuffer
Date: Sun, 26 Mar 2023 13:44:43 -0700

Hello,

X-debbugs-cc: joaotavora <at> gmail.com

On Fri 24 Mar 2023 at 12:39PM GMT, João Távora wrote:

> As far as I know, the "unobtrusive" part of Icomplete &c is designed
> primarily to let you modify the search pattern upon which Icomplete
> is acting to show you potential candidates for the thing you ultimately
> want to complete to as quickly as possible, so that if I type, say
>
> M-x fido-mode
> M-x
> f o o
>
> then the search for all commands whose name contains 'f' is interrupted,
> and any results discarded,  as soon as I type the 'o', the 'o' is shown
> in the minibuffer, and a search starts anew.  This is realized with
> while-no-input. If the completion backend is particularly slow in searching
> (which is usually not C-x b's case, but other backends are indeed slow), this
> helps a lot in seeing what you are typing.
>
> As far as I know, this behavior is _not_ designed to "tweak" the
> C-g behaviour to be anything different from what you would get
> if you were not using Icomplete or Fido mode.

Thank you for this summary.  So, this is pretty much a feature request
to extend the unobtrusiveness a bit further, if we can.

> That said, I don't understand exactly what you want to happen when you
> type C-g before the search is complete, what happens instead, and why
> do you think you're seeing a bug.

Okay, how about this.  As you describe, typing any self-insert chars
while Icomplete is computing what to display cancels and restarts that
computation.  The primary purpose of this, as you say, is to allow the
user to modify the search pattern as quickly as possible.

A slightly broader way to understand the same thing is as allowing the
user to /ignore Icomplete until they've finished inputting/ their
pattern.  So, if Icomplete starts computing essentially bogus
completions, because I'm still typing my initial input, I don't have to
do anything special to restart the search.

We can make this broader: instead of allowing the user to ignore
Icomplete just while inputting the initial pattern, I'd like to be able
to /ignore Icomplete until and unless I want to use its bindings/.
While I'm still inputting my initial pattern, I want to ignore Icomplete
because I'm not ready to complete.  Similarly, if I hit C-g to cancel
minibuffer input, I would like to be able to ignore Icomplete because,
again, I'm not interested in doing any completion.

Many instances of completing-read are invoked by the user in order to
enter arbitrary strings, and not to do any completion, even though it's
available.  I would like to be able to C-g out of these, as though
Icomplete weren't there at all, because I have no interest in using it.

However, as I described, if your C-g is unfortunately timed it gets
caught by the Icomplete computation and so doesn't exit the minibuffer.
Perhaps we can extend this so that it doesn't matter what moment the C-g
comes in.

-- 
Sean Whitton

Previous Next

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