bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press

["João Távora" <joaotavora@gmail.com>]

On Fri, Mar 24, 2023 at 12:01 AM Sean Whitton <spwhitton@spwhitton.name> wrote:
>
> On Thu, Mar 23, 2023 at 10:09:00PM +0200, Eli Zaretskii wrote:
> >
> > It isn't a bug, but the expected and intentional behavior.
>
> I thought that the idea with Icomplete &c. was that they would stop what they
> are doing in response to any keystrokes, not requiring an explicit quit, in
> order to be maximally unobtrusive.

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.

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.

João