all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: Juri Linkov <juri@linkov.net>
Cc: emacs-devel@gnu.org
Subject: Re: Suggestions for improvements to the *Completions* buffer
Date: Mon, 13 Dec 2021 19:16:11 +0000	[thread overview]
Message-ID: <87ilvs71tw.fsf@posteo.net> (raw)
In-Reply-To: <86y24tjzqn.fsf@mail.linkov.net> (Juri Linkov's message of "Thu,  09 Dec 2021 22:21:36 +0200")

Juri Linkov <juri@linkov.net> writes:

>>>> +(defun completion-quit ()
>>>> +  "Close the completion buffer and return to the minibuffer."
>>>> +  (interactive)
>>>> +  (quit-window)
>>>> +  (switch-to-minibuffer))
>>>> +
>>>> +(defun completion-kill-buffer ()
>>>> +  "Close the completion buffer and return to the minibuffer."
>>>> +  (interactive)
>>>> +  (kill-buffer "*Completions*")
>>>> +  (switch-to-minibuffer))
>>>> @@ -8970,10 +8982,12 @@ completion-list-mode-map
>>>> +    (define-key map "z" #'completion-kill-buffer)
>>>> +    (define-key map [remap keyboard-quit] #'completion-quit)
>>>> +    (define-key map [remap quit-window] #'switch-to-minibuffer)
>>>
>>> So typing C-g in the *Completions* buffer will be the same as
>>> typing C-g in the minibuffer?  This would provide more consistency.
>>
>> No, currently not: C-g will close the completions buffer, "reverting" a
>> change so to say, and another C-g in the minibuffer will cancel the
>> completion.
>
> I misread the patch.  Then double C-g C-g will be like in Isearch where
> the first C-g cancels wrong characters, and another C-g cancels the search.

Yes, didn't think of that but good to be reminded that there is already
a precedent for this kind of behaviour. 

>>>> In the *Completions*, self-insert-command is not bound so that "q", "n",
>>>> "p", "z", ... can be used.  This patch would add "s" (for
>>>> isearch-forward) and "S" (for isearch-forward-regexp) to the default
>>>> bunch.  This is my most recent change, that I am least certain about.
>>>> If I played around with it for a bit longer, maybe this could also be
>>>> extended to an interactive narrowing along the lines of icomplete.
>>>
>>> I guess it's too late to allow all self-inserting keys in the *Completions*
>>> buffer to be used either to add characters to the search string,
>>> or to narrow completions interactively as if they were typed in the minibuffer,
>>> because "q", "n", "p", "z" are already bound to other commands?
>>
>> True, so immediate narrowing (at least with the default bindings)
>> couldn't be done, but that doesn't mean that narrowing couldn't be
>> enabled by binding an activation command to conventional keys like "s"
>> and "/".
>
> Wouldn't it be easier just to switch to the minibuffer (with e.g. 'q')
> and continue narrowing by typing more characters in the minibuffer?

That is what it would basically boil down to.  The question is just
should "q" quit close the completion window or now.

-- 
	Philip Kaludercic



  reply	other threads:[~2021-12-13 19:16 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09 17:22 Suggestions for improvements to the *Completions* buffer Philip Kaludercic
2021-12-09 17:49 ` [External] : " Drew Adams
2021-12-09 18:05   ` Philip Kaludercic
2021-12-09 19:21     ` Stefan Monnier
2021-12-09 18:27 ` Manuel Uberti
2021-12-09 19:49 ` Juri Linkov
2021-12-09 20:07   ` Philip Kaludercic
2021-12-09 20:21     ` Juri Linkov
2021-12-13 19:16       ` Philip Kaludercic [this message]
2021-12-09 21:16     ` Stefan Kangas
2021-12-13 19:13       ` Philip Kaludercic
2021-12-13 21:36 ` Philip Kaludercic
2021-12-14 21:13   ` Juri Linkov
2021-12-17 11:27     ` Philip Kaludercic
2021-12-17 15:00       ` Philip Kaludercic
2021-12-18 12:22       ` Philip Kaludercic
2021-12-18 12:31         ` Po Lu
2021-12-18 13:39           ` Philip Kaludercic
2021-12-20  1:13             ` Po Lu
2021-12-18 17:41         ` Juri Linkov
2021-12-19 14:55           ` Philip Kaludercic
2021-12-19 17:18             ` Juri Linkov
2021-12-19 23:58               ` Philip Kaludercic
2021-12-20  9:03                 ` Philip Kaludercic
2021-12-21 19:02                 ` Juri Linkov
2021-12-21 21:32                   ` Philip Kaludercic
2021-12-22  7:54                     ` Daniel Semyonov
2021-12-22  9:04                       ` Juri Linkov
2021-12-22  9:56                         ` Daniel Semyonov
2021-12-22 17:42                           ` Juri Linkov
2021-12-22 12:27                     ` Eli Zaretskii
2021-12-18 17:40       ` Juri Linkov

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

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

  git send-email \
    --in-reply-to=87ilvs71tw.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.