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: feature/completions-highlight-modifications e3c5b99 3/6: Add completions-highlight-mode initial implementation. Date: Thu, 19 Nov 2020 09:45:04 +0200 Organization: LINKOV.NET Message-ID: <87d009kfmf.fsf@mail.linkov.net> 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> <87d00acuh3.fsf@mail.linkov.net> <20201119032519.lpa53ixezgpdppze@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18807"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: Stefan Monnier , Drew Adams , emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 19 08:58:19 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 1kfepf-0004jk-3e for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Nov 2020 08:58:19 +0100 Original-Received: from localhost ([::1]:56818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfepd-0000WS-KV for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Nov 2020 02:58:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfep3-0008Hm-04 for emacs-devel@gnu.org; Thu, 19 Nov 2020 02:57:41 -0500 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:61381) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfep0-0001TY-E2 for emacs-devel@gnu.org; Thu, 19 Nov 2020 02:57:40 -0500 X-Originating-IP: 91.129.97.46 Original-Received: from mail.gandi.net (m91-129-97-46.cust.tele2.ee [91.129.97.46]) (Authenticated sender: juri@linkov.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id A08DE40002; Thu, 19 Nov 2020 07:57:32 +0000 (UTC) In-Reply-To: <20201119032519.lpa53ixezgpdppze@Ergus> (Ergus's message of "Thu, 19 Nov 2020 04:25:19 +0100") Received-SPF: pass client-ip=217.70.183.194; envelope-from=juri@linkov.net; helo=relay2-d.mail.gandi.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/19 02:57:34 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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:259413 Archived-At: > I made some of the changes you suggested, I think the behavior is a bit > more reliable now. Thanks. Please see more comments. >>The problem is that such TAB cycling is limited only to the case >>when the whole *Completions* buffer is visible. >> > This was as I said intentional. And to change that could be relatively > easy but I am not 100% we should. Maybe with a custom in the future... To be able to merge the branch to master, all its features should work without problems, but the TAB cycling feature is broken by design: sometimes it scrolls completions window, sometimes moves to next completion. This behavior is unpredictable to users. So I suggest first to implement more straightforward features, and leave such controversial features at the last thing to do. >>3. commands that dispatch navigation keys from the minibuffer to the >> *Completions* buffer: this doesn't cover other navigation keys. >> >>Maybe like windmove-default-keybindings defines modifiers, >>a similar function could set up modifiers for scrolling completions >>from the minibuffer, then the users could choose whether to use >>e.g. 'M-' modifier for scrolling completions, or no modifier at all. >> > I will try that when have some time. This could also allow the user to select what keys to dispatch to the *Completions* buffer. For example, TAB and S-TAB move to the next/previous completion in the *Completions* buffer, so it makes sense to do the same from the minibuffer as well (optionally). >>4. the feature of using completions-highlight-overlay often fails to >> update highlighting when point is moved in the *Completions* buffer >> by other navigation commands. >> >>To fix this, it could work like hl-line-mode, but instead of >>highlighting the whole line, it could highlight only completions. >> > I didn't use the post-command-hook before because I didn't know about it > when I started and then I forgot to fix that. Please give it a try now. Highlighting completion under point is useful on its own. It makes sense for the users to enable it separately from other features, like hl-line-mode is useful on its own. > Maybe not a custom but a minor mode is better and simpler. It is just to > divide my current code in two minor modes instead of just one. hl-line-mode is a mode because it can be useful in any buffer, but completion highlighting is useful only in the *Completions* buffer, so it can be a user option. >>Then completion highlighting would be useful on its own. >>A new defcustom e.g. 'completion-highlight' (disabled by default) >>could add a post-command-hook like hl-line-mode does. >>Then other completion commands could enable this variable locally. > > I made this on the beginning, but I didn't want to add more code to > simple.el... Adding much more code to simple.el is undesirable indeed, but for the completion highlighting feature it would take only ~20 lines of code and option/face definition in minibuffer.el. All the remaining features need own package file indeed. BTW, the file name completions-highlight.el is too ugly as a package name. An example of a good package/mode name is icomplete.el. A new package that allows navigation of completions from the minibuffer could be like icomplete.el in other regards too: define the mode/keymap in the same way, use similar options/hooks, etc.