From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: feature/completions-highlight-modifications e3c5b99 3/6: Add completions-highlight-mode initial implementation. Date: Tue, 17 Nov 2020 01:46:53 +0100 Message-ID: <20201117004653.thnefjkbj73ao4yk@Ergus> References: <20201115023629.19537.77471@vcs0.savannah.gnu.org> <20201115023631.C78AB20A27@vcs0.savannah.gnu.org> <20201115224943.o5r7lkkblmyt2ox4@Ergus> <20201116033719.63dryvqm4ozfer2r@Ergus> <92f3cbd7-29a0-461a-a023-562bc6020ea8@default> <87v9e5herj.fsf@mail.linkov.net> <20201116102729.ywubtda6cqdzc45z@Ergus> <877dql59v0.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1449"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Drew Adams , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 17 01:47:52 2020 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 1kepA0-0000HH-8s for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 01:47:52 +0100 Original-Received: from localhost ([::1]:40320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kep9z-0001B1-BC for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Nov 2020 19:47:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39338) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kep9R-0000lV-3R for emacs-devel@gnu.org; Mon, 16 Nov 2020 19:47:18 -0500 Original-Received: from sonic309-15.consmr.mail.bf2.yahoo.com ([74.6.129.125]:42805) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kep9N-0006UZ-1C for emacs-devel@gnu.org; Mon, 16 Nov 2020 19:47:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1605574029; bh=TQ4DPimPrz60wxoVjgzJOlxbiHKkR+IKZyavSicUqMw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=fLa77/IrGj6E0bEH8FBuuFIMHWxnJ+4JyploVIXYBgKSa6okBvuy1MFxf01tUvKALSGjYvK2X/xKaGS4weNMUU6hK+6MC37QJdYEgA1/B/t4PtdVf9apqtqEbk4MyW+AbIgA3M5WG3HjDILrdBQxhk9kJuwN7azhuCmbWjWEsSCGQ4cGGZWlW82WKjPeIid7RaAn/cWJJKMLYxqSSd9olriYLtAqHA6tvVJz2ihNxtDv1Qes4MXavGc79vyBmTw963A90KloDCELZob0mVEyYBmphPp/G4okFBeu5dY8DHZx6MB5ohN6aXOrFXSqiVXRDH7wm1Yd0GYsin6OZLQpaQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1605574029; bh=/e/wlHj0neahfyZ+voNc+etvFtLSCuAydt6bQ6zxo5C=; h=Date:From:To:Subject:From:Subject; b=lWpmyjbzCI6QVK1pPrjXfcK2j5mNUKlbIYVTJp4SHAI4iJ0arTEk+ETwxErfh9gWM6al2/k53IkKE6uvWhe0BBHLQWSbGK8mTipY5vHbwLlwMPg35eQM8dFKXYUXk0JXUfNoqZv1sBcFPYV3p+KzuCXkb4s1jFK8zMP1spH7ximAJBlabH7mjhiLJzNUVrKftvMYVsyNv3nGw3GxhbU53Ld5JLwSnDBmqhyjS5XhoEUSEsyinQ1tHSiORPtYjdkLeLw2BZma6So5RZbFCqgN0uwPnbIr/EtFf+1TV8Rn8ONXCfGFvZgYudW3Yv49FLYrogQwOEwxClgTebD98IHQCw== X-YMail-OSG: vnbenQMVM1nmLCDuBSAeN4mSeVN0t8IHvfvbt07uBYeLuxm9eb_kukkfVkTazZt 9WzzND8r26NXrOC6PE4f_Fv6pHuUpKj3xCzfB7Y5SWaXtd_Bn24YCoO4qUeOxtWQoeu4HvaAUOHE 6Xd1vrji9DAY__MyxyUS8Ke5Jv_qFNvvZLFUUP76w76rjDxWq2m1J44tUbWQjEsVRDxFTBwlJvEx aDNFGBoULz440YGBVItAAQc49lGP30ftFpmGKzf4QXv35ETJFal1znDSqPqa7VOyrUOait.SNqh6 iQ79oROo0VKDidvLrpedy1wLZVnu.fLP9D0W3SyEfXKFJ2HuTDX2NnHgjXMF8A2LfoM4wLhi3TTU ZaZvMFJZT0ofPgfcuyzp4iXf9KGwluhMs2Z.RhuMwoQWJZd.tLV5hOhQOib_HNZnOXZxa1z_.bLB dUgIkCrueX5ehZ4Ha23b57e0.9pIYk1KGkJoWX2aVc4xPOPPCzGmEaloR.3UAF8QMjHuMmSUYyHA _YvkJkIQIviOan45NxqGsF_HwwY.Jdc0YYpclUKHHOr7ntCvoDfCfMadsgPx2gXr_cwFUvjhB0Vd dzOMxW7gdoZqKYZ4y4c5unr4tZe46AMk880cX7jMOUbrsgDokfAcXM52rPUOkgv6JwIdbU0UCQUB _4mmEAj5cdmM4ZJwj4eZHb.AHELAu8s7OFlc8i05P.g353bP4Eujd0lZUMy3KXe2pWcmjtRs1SqQ Y8j15fkRlXBP371qMblalwTds0QJgxyXse0wmzUzSMbd_oV1IaI_nVAJyHYD4nBsUIIBfuLWIrk. mtZcsQsyPEXXH6jnzhqKOnDLfNdxb5mrHMZZL8tM.1 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 17 Nov 2020 00:47:09 +0000 Original-Received: by smtp411.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2b27dd8290bcbcb3ab03ff83d37db740; Tue, 17 Nov 2020 00:47:07 +0000 (UTC) Content-Disposition: inline In-Reply-To: <877dql59v0.fsf@mail.linkov.net> X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Received-SPF: pass client-ip=74.6.129.125; envelope-from=spacibba@aol.com; helo=sonic309-15.consmr.mail.bf2.yahoo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/16 19:47:09 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.23 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:259269 Archived-At: On Mon, Nov 16, 2020 at 10:23:47PM +0200, Juri Linkov wrote: >> With the current implementation this is not supposed to change. Of >> course there is space for improvement and there are bugs, but so far, >> all navigation still works in *Completions* buffer as usual because I >> just added some commands. If there is anything that breaks the normal >> previous behavior somehow, please tell me; because I put special >> attention to prevent that. > >Sorry, I was not clear enough: I meant that the new feature doesn't >allow in the minibuffer using the same navigation keys that are >already available in the *Completions* buffer, e.g. and >typed in the *Completions* buffer scroll it up and down. > I didn't change any default current behavior because I tried to prevent complains when proposing to enable this by default in a future (as I said "A man can dream"). In the code there is a macro `with-minibuffer-scroll-window' that execute any command in the Completions buffer only when it is enabled but also the completions-highlight-minibuffer-map is set in completion-setup-hook, so, after the completions are visible only. Basically we only need to add the command you propose like (defun ... (with-minibuffer-scroll-window scroll-up-command)) And bind them... probably with a remap in completions-highlight-minibuffer-map. >For example, while in the minibuffer type 'TAB' that displays a very >long list of completions, then type 'C-M-v', and see how it scrolls the >*Completions* buffer. When the list is too long the highlight is not enabled now. This can be seen as an issue or a feature, because it keeps the previous behavior and requires minimal changes in the minibuffer.el side. >Better yet try typing and >in the minibuffer, and see how it scrolls the *Completions* buffer >up and down. I meant that a new feature could allow such page scrolling >without the 'M-' modifier, by just using and in the minibuffer >(and C-v/M-v as well) to scroll the *Completions* buffer. > will break the current behavior... there will be complains if we try that and we will waste precious time in this mailing list trying to get an agreement to go nowhere (as usual). In any case all them are trivial to implement and even simpler with a remap. C-M-v only scrolls Completions in some conditions. If you move forth and back from another buffer then that one will be the one scrolled instead of Completions. IMO this is a confusing behavior, but try to change that and for sure will be the end of the world for some users.... so we need more customs :). >> We could add a custom to disable the new bindings in the *Completions* >> if you think is better; because IMO the most important thing is to >> "navigate" with arrows the completions from the minibuffer without >> leaving it; and the overlay. > >Maybe a custom could provide some DWIM behavior by default, >e.g. to activate these keys only when the *Completions* buffer >is displayed. > This is also trivial to do... but I prefer to know if there is an agreement in favor of the current unobtrusive changes before extending it more.