From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Juri Linkov <juri@linkov.net>
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>
 <ier34ye4a3x.fsf@janestreet.com> <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 <sbaugh@catern.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 18 19:36:49 2023
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	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 <emacs-devel-bounces@gnu.org>)
	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 <juri@linkov.net>) 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 <juri@linkov.net>) 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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=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: <http://permalink.gmane.org/gmane.emacs.devel/311558>

>>>> 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.