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: Thu, 19 Nov 2020 11:50:52 +0100 Message-ID: <20201119105052.kfichqojkhfwwsiz@Ergus> References: <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> <87d009kfmf.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="6529"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Drew Adams , Stefan Monnier , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 19 11:52:43 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 1kfhYR-0001aw-CJ for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Nov 2020 11:52:43 +0100 Original-Received: from localhost ([::1]:47568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfhYQ-0002PP-A7 for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Nov 2020 05:52:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfhX8-0001Xx-LM for emacs-devel@gnu.org; Thu, 19 Nov 2020 05:51:22 -0500 Original-Received: from sonic313-13.consmr.mail.bf2.yahoo.com ([74.6.133.123]:38376) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kfhX1-0004p0-3a for emacs-devel@gnu.org; Thu, 19 Nov 2020 05:51:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1605783071; bh=5whMNrK8F1QIHKNgflCpQ36MXpAQ8JnO3WQCusgzq8o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=mgzzSk9DFxP34wx6xT5b6KgKDinvbI0/Fekjh9zK0in6ZAoFrZyERb3b5HbncO6znDKd7useaVLn4yWWeoDj3NyGxRoXtY6KuU0iXczqFQcsADjZGAyZnvPxiFVrsc+h2zoUp2cOyJ2yERg83tv1Gjw6VUABgoID9shufjh3/G0O+hUqB3BhlofZxghyoAJQVzuw1StUvezKQTVwEDfuPC7vjiyxxguj2HAiG/5kzq9LxFyz6fg96Zlbjf7C4hB9n+FolwsAIbxvQlu4j/WELcka8IfPRRhUdZ8q2NfxSGPbIDimc9IIf2dZz+c8UnhhKhwaaW2T5ERCIwyAMOHZbg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1605783071; bh=XBI5igmLCBulvsIfiJ/s8XUvRuPc37VNCx14AHCWPK5=; h=Date:From:To:Subject:From:Subject; b=fx1FjB/sQrEJthpjddxmn22kTZK/gBHDefQ4PMltGRR1LM9mSismiNVu6ms/69321W6UrRt0Ophj/CIkUUdKRk9u5Javbtn7A8TiAYjMjYOz46oDOKpMBo/mUfUtqL8kEI84Ive7kSD/NCt8V8RFmw4Od+F/IEEpk1CLEaP/U7k5VpkEwX6X/QJ85Jh1LmycAHk7wuKYwE3BTYf24fnbd4eXqP8ymZwqSHs0z68DiqB9W1kbAOk/4VSSzvE3PP7abmVTE0wnN/Cyns1GgKomOpt8xyrz6I5luhFsHg0V2vOIEqckJ1OH5aiXQ1gF9JfQCM2Y0S2nA4E/SZ0VnUtLpQ== X-YMail-OSG: czsRGGEVM1kSZygb5LvUq1ZjmP7cjyk63k7KYfNV3gsrrqhg5S0pf7gpj6VZwQk W3hq9BuQdRoHApzSPaF_75KKxPB8asXDuqixVF_9lOAueclanuL7YYuJv.xllU8ivghMHKEnvjgl TGNoxo0NQevvqHhYiU0yDIQkO1NFZSMYgW_AiQRY4CzqJj.uruY6to97M2BeteiYOBzlt8KSis20 f7_yiUNj32RIt2A9PAn.0RWYPS2lHhqzS3s94mjICyc3a16SKMcPFwMQFqJjAiY0nmhGyFbLLBOU vzdn1bFwxCiZ9RgooIIekKoKL8HhNjFs03le5deM7burJ_X9f7ak4oPY_8QE0EL1MVazkfybWRBp XnSzOrMi67OriWpYqiqprJGk8gZnSRS4fdSA52rzMPdaAVAbHJjnxNfyMjgS7lZJNNOtfBpybKZ9 ZhlDpC0glLKl5fSBQjFw00wD3g.Lanj6IiiYWkJ4BYDvlB3da_jc5D9Il3qa9TYzWe0G3F8fN6DT 9xqy9XmsBa7d0nMyP13vv9lQ0d5MDEWyViPIAYo02M7hK5twd0EBqVWb2VAQoGlKj8MXybijT83m 6rkZmYDKAzmV_.AUZb3tTaOYRJW9oBX45pvc2ue.0f5QipcieSkQ7FSzIz6rM_ATFd.gy2Dmy0yB RRidgo5ntdMD2ftaVMl5XR6LYjfcA0NskMbu2b2ImZ1ztVPE7ZBqlMKQnXiHUuXl8AgbdwpRkNEd 0aWsm6K.Oo2aDHcMhnQdCAcbDrpOPijEdLcnBkX2_VZuRfe3EvYLREMGOTT3u0kMXMPgUMq.LSSN 3qcoLr8PABH37PRK_TYn..c4KOPmV5OJsgQGUyq62Y Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Thu, 19 Nov 2020 10:51:11 +0000 Original-Received: by smtp416.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9042a8d3cf67d7b01b2642868d5e210c; Thu, 19 Nov 2020 10:51:07 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87d009kfmf.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.133.123; envelope-from=spacibba@aol.com; helo=sonic313-13.consmr.mail.bf2.yahoo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/19 05:51:11 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:259420 Archived-At: Hi Juri: Thanks for your time ;) On Thu, Nov 19, 2020 at 09:45:04AM +0200, Juri Linkov wrote: > >Thanks. Please see more comments. > > >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. > I agree. The current tab design is IMO broken by itself but that's not something I intended to change. In any case the arrow keys are there in a more consistent way to move... and as we know, there will be never an agreement on this. So it is better if we find a way to set that unilaterally to what we think is better and add a custom to disable it.... More extensions, better alternatives and complains will come out with the time whatever we do. > >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). > I understand the idea, but IMO this is pointless. Because M-* or S-* is not better than just pageup + whatever. I don't find the zsh behavior confusing an that was my pattern from the beginning. I am worried because adding more and more bindings (even with a prefix) may a) Conflict with existing bindings/default current behavior b) Lead some useless complex combinations like C-M-someting (that does not work in the terminal very often BTW) c) conflict with some frequently user-defined bindings. For example S-arrow now is used to select the region and M-arrow to backward word Maybe we should look more how zsh behaves... and try to mimic that as much as possible. Because it is already pretty consisten > >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. > >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. > Yes, but this actually works as a hook, so we need to add/remove the command to/from post-command-hook. That's easier and cleaner with a mode (or a toggle-something command) than with a custom right?. (please, remember I don't know the deep lisp secrets, so maybe there is actually a better way) > >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. > Indeed. I already did that on the beginning, but then I moved it out. Actually If I can choose it will be better if all the *Completions* stuff are moved to their own file... But that's a task for a good developer, not me ;p. There is actuallu the completion.el I am not sure what's there. >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. I agree, but we have display-fill-column, display-line-numbers... In any case I don't care the name at all; so I will just ask here for names, and when the war ends I just obey the winner orders.