From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Suggestions for improvements to the *Completions* buffer Date: Mon, 13 Dec 2021 19:16:11 +0000 Message-ID: <87ilvs71tw.fsf@posteo.net> References: <87a6h9g0c0.fsf@posteo.net> <86wnkdmude.fsf@mail.linkov.net> <874k7hee4j.fsf@posteo.net> <86y24tjzqn.fsf@mail.linkov.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="3423"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 13 20:18:43 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 1mwqqR-0000fc-7e for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Dec 2021 20:18:43 +0100 Original-Received: from localhost ([::1]:51572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mwqqP-0006Xx-UU for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Dec 2021 14:18:41 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34216) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwqoD-0005Tn-7V for emacs-devel@gnu.org; Mon, 13 Dec 2021 14:16:25 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:46855) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwqo5-00057D-0W for emacs-devel@gnu.org; Mon, 13 Dec 2021 14:16:18 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id EFE4A24010C for ; Mon, 13 Dec 2021 20:16:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1639422973; bh=J2K/f9hZZMPcafUQgC7+0sI1ZdqiR0pw73qFYMg/K/Y=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=YpSfGs0lOh6gzTrF2D1GLvDduY0Y5s0ytYvzqzaWORkaQfbbxMGZd2wsoC82UDctL bxNxNGZJX9MO8/jwe/B3KBe+F+VKc9l+wYHrx9jilScLw/RzWvCYTZbWGaE85O5+4p wCzUBZ5g0H8hb59GZsSff4MmqzoQ4KMMA9RE9rb2dwP6A15/c33/61o3R2k8ewBOEA jq16Dzy5rb61CczPdbMFYjOTGm6alBIJoFrNFQE80cbVZdfPf3Slvj8+hHh+jogVoV +1oDh2Vkwoi8N2augJ83Zp1JyNYGOj5I+tGbxZc0/aDN+ya3kcTI194AitiMiUqNEY z5CamNvWmYaYQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JCWSq721Tz9rxF; Mon, 13 Dec 2021 20:16:11 +0100 (CET) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: <86y24tjzqn.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 09 Dec 2021 22:21:36 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:281862 Archived-At: Juri Linkov 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