unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Sean Whitton <spwhitton@spwhitton.name>
To: 62468@debbugs.gnu.org
Subject: bug#62468: 30.0.50; Improve Icomplete while-no-input s.t. C-g quits the minibuffer
Date: Sun, 26 Mar 2023 13:44:43 -0700	[thread overview]
Message-ID: <87o7ofckec.fsf_-_@athena.silentflame.com> (raw)
In-Reply-To: <CALDnm53n=UOnaNwznh1OMvCAnJ6B+h=m-vXHzqxJP6u2Gq4zyQ@mail.gmail.com> ("João Távora"'s message of "Fri, 24 Mar 2023 12:39:29 +0000")

Hello,

X-debbugs-cc: joaotavora@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





  reply	other threads:[~2023-03-26 20:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 19:16 bug#62355: 30.0.50; C-g doesn't always quit minibuffer on first press Toon claes
2023-03-22  3:29 ` Eli Zaretskii
2023-03-23 19:31   ` Sean Whitton
2023-03-23 19:47     ` Drew Adams
2023-03-23 20:09     ` Eli Zaretskii
2023-03-24  0:01       ` Sean Whitton
2023-03-24  6:12         ` Eli Zaretskii
2023-03-24  7:56           ` Toon Claes
2023-03-24 11:56             ` Eli Zaretskii
2023-03-24 15:32               ` Toon Claes
2023-03-24 18:32                 ` Eli Zaretskii
2023-03-24 19:17           ` Sean Whitton
2023-03-24 12:39         ` João Távora
2023-03-26 20:44           ` Sean Whitton [this message]
2023-03-24 21:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7ofckec.fsf_-_@athena.silentflame.com \
    --to=spwhitton@spwhitton.name \
    --cc=62468@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).