emacs-devel
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]