[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggestions for improvements to the *Completions* buffer
From: |
Juri Linkov |
Subject: |
Re: Suggestions for improvements to the *Completions* buffer |
Date: |
Thu, 09 Dec 2021 22:21:36 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) |
>>> +(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.
>>> 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?
Re: Suggestions for improvements to the *Completions* buffer, Philip Kaludercic, 2021/12/13
- Re: Suggestions for improvements to the *Completions* buffer, Juri Linkov, 2021/12/14
- Re: Suggestions for improvements to the *Completions* buffer, Philip Kaludercic, 2021/12/17
- Re: Suggestions for improvements to the *Completions* buffer, Philip Kaludercic, 2021/12/17
- Re: Suggestions for improvements to the *Completions* buffer, Philip Kaludercic, 2021/12/18
- Re: Suggestions for improvements to the *Completions* buffer, Po Lu, 2021/12/18
- Re: Suggestions for improvements to the *Completions* buffer, Philip Kaludercic, 2021/12/18