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: Updating *Completions* as you type Date: Wed, 18 Oct 2023 20:28:44 +0300 Organization: LINKOV.NET Message-ID: <86jzrjvohz.fsf@mail.linkov.net> References: <87bkd3z9bi.fsf@catern.com> <86cyxjyr1y.fsf@mail.linkov.net> <86r0lxm7um.fsf@mail.linkov.net> <87o7gxwaxe.fsf@catern.com> <86a5shyw48.fsf@mail.linkov.net> <874jiox1km.fsf@catern.com> <86jzrk8lui.fsf@mail.linkov.net> <87o7gwumfj.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2175"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 18 19:36:49 2023 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 1qtATQ-0000PZ-PT for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Oct 2023 19:36:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtASn-00014p-GX; Wed, 18 Oct 2023 13:36:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtASl-00014E-74 for emacs-devel@gnu.org; Wed, 18 Oct 2023 13:36:07 -0400 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtASj-0001rJ-Bc for emacs-devel@gnu.org; Wed, 18 Oct 2023 13:36:06 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id C7772E0008; Wed, 18 Oct 2023 17:36:01 +0000 (UTC) In-Reply-To: <87o7gwumfj.fsf@catern.com> (Spencer Baugh's message of "Wed, 18 Oct 2023 12:47:45 +0000 (UTC)") X-GND-Sasl: juri@linkov.net Received-SPF: pass client-ip=217.70.183.196; envelope-from=juri@linkov.net; helo=relay4-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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311558 Archived-At: >>>> BTW, while looking at this case I found a problem with your first patch: >>>> after navigating in *Completions* and switching back to the minibuffer >>>> point is reset to the beginning of the *Completions* buffer. >>> >>> Good catch! If you see my other patch which I posted in this thread, >>> "Keep point on the same completion in the completions buffer", that is a >>> nice orthogonal improvement which incidentally also fixes that bug in >>> completions-auto-update. >> >> Your third patch adds a new feature that just hides the bug by forcing >> the previous position over the wrong new one. I think the proper fix >> would be to add more commands to completions-no-auto-update-commands >> in your first patch. Or to change it from opt-out to opt-in by renaming >> to completions-auto-update-commands. > > I would much rather not list commands as opt-in or opt-out at all, I'd > rather all commands just work without special cases. So I'm working on > features to allow that. > > I don't agree with the characterization of "it just hides the bug". The > bug is that point in *Completions* gets wiped out by auto-updating. My > third patch preserves point across auto-updating. That's very directly > solving the bug. I agree it's helpful to keep point on the selected candidate while adding characters to the completion. But the problem is that point is kept for too long that affects later unralated commands. >>>>> I think this has some nice benefits in reducing the number of concepts >>>>> people need to track. If the minibuffer is empty, they can just use >>>>> minibuffer-next-completion a few times followed by RET to select a >>>>> completion, no need to use M-RET. Plus, the new M-RET and C-u M-RET >>>>> would be useful even to users who don't use minibuffer-next-completion. >>>>> True, good analysis. >>>> >>>> Specifically though it's about the case when the minibuffer is empty. I >>>> think it would be nice for RET to submit the highlighted candidate in >>>> that case, if there is one. >>>> >>>> That matches icomplete-mode's behavior, actually, which is nice. >>> >>> Oh, actually it doesn't. It matches ido-mode and fido-mode and a host >>> of completion mechanisms outside core, though. I still think it's >>> desirable, at least as a user option. >> >> But then such idiosyncrasy of fido-mode causes a lot of bug reports >> like bug#55800. > > But we would not have those kinds of issues because when completion > starts, by default, there is no highlighted candidate. And the issue occurs as soon as the first candidate is highlighted.