From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Suggestions for improvements to the *Completions* buffer Date: Thu, 09 Dec 2021 21:49:17 +0200 Organization: LINKOV.NET Message-ID: <86wnkdmude.fsf@mail.linkov.net> References: <87a6h9g0c0.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17436"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 09 20:52:42 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvPT8-0004Qp-1X for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 20:52:42 +0100 Original-Received: from localhost ([::1]:58022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvPT6-00010k-VK for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 14:52:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvPSa-0000ME-C2 for emacs-devel@gnu.org; Thu, 09 Dec 2021 14:52:08 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:48771) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvPSX-0001Gg-Pd for emacs-devel@gnu.org; Thu, 09 Dec 2021 14:52:07 -0500 Original-Received: (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 23FECFF805; Thu, 9 Dec 2021 19:52:00 +0000 (UTC) In-Reply-To: <87a6h9g0c0.fsf@posteo.net> (Philip Kaludercic's message of "Thu, 09 Dec 2021 17:22:23 +0000") Received-SPF: pass client-ip=217.70.183.199; envelope-from=juri@linkov.net; helo=relay9-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281538 Archived-At: > I'd like to suggest a few modifications to the default behaviour of > the *Completions* buffer. These are mostly conservative extensions of > the current defaults. Thanks, all your patches is a nice improvement. I have a question only about the last patch. > When exiting the *Completions* buffer, C-g and q seem not to send the > user back to minibuffer. This was just a plain bug. > +(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. > 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?