From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Spencer Baugh <sbaugh@catern.com>
Newsgroups: gmane.emacs.devel
Subject: Re: Updating *Completions* as you type
Date: Wed, 18 Oct 2023 23:32:10 +0000 (UTC)
Message-ID: <87a5sfv75y.fsf@catern.com>
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> <86jzrjvohz.fsf@mail.linkov.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="25245"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: emacs-devel@gnu.org
To: Juri Linkov <juri@linkov.net>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 19 01:34:07 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 1qtG3C-0006Hq-Ay
	for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Oct 2023 01:34:06 +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 1qtG1W-0004ca-2L; Wed, 18 Oct 2023 19:32:22 -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 <bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com>)
 id 1qtG1P-0004WN-Be
 for emacs-devel@gnu.org; Wed, 18 Oct 2023 19:32:15 -0400
Original-Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1)
 (envelope-from <bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com>)
 id 1qtG1N-0000PH-Aa
 for emacs-devel@gnu.org; Wed, 18 Oct 2023 19:32:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com;
 h=from:subject:in-reply-to:references:mime-version:to:cc:content-type:
 content-transfer-encoding:cc:content-type:from:subject:to;
 s=s1; bh=fe4U+nonD3Vv5vfUkJlzEsJDPg7ULfPJjV1LZTSsSA0=;
 b=XMCnH21Up4JeknuLBJsJjPOVA0Iizy+Lms1q61bbuu6bSeiZj+PJIm6IEeHghlD5m8Me
 yR2fGk1cruvbyYjplxbtTC5+Rv/H5QD60Z0s0v67ZURojxtmdJiOwNumTiSEQx6MXrJ9Bc
 TJ27l9YMXnGsb+EvoEwM0dAQoOgxT+pUrcfUu9npfUJvZNGuN9W//SIsLIW5b+UkNGjdys
 HbrLnBNhk4LWZ28xZRMN4pRcLsPUoGsv4FthETMPFaPI3QHYQBWRA7Z4hfj944q+Yr/4tW
 b9ZvyZPq0w8ZUpjZ7+89lRVKSRs9rcTBSwwQBcsXF7iPYAm5Cc/Vo9vs7r8dCsDg==
Original-Received: by filterdrecv-b85775b64-c6l9v with SMTP id
 filterdrecv-b85775b64-c6l9v-1-65306AFA-14
 2023-10-18 23:32:10.453521374 +0000 UTC m=+103867.171824611
Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-14 (SG) with ESMTP
 id mRvdtXj3Rk6sXNhxNKOGGQ Wed, 18 Oct 2023 23:32:10.278 +0000 (UTC)
X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost;
 envelope-from=sbaugh@catern.com; receiver=linkov.net 
Original-Received: from localhost (localhost [IPv6:::1])
 by earth.catern.com (Postfix) with ESMTPSA id C8D0366E61;
 Wed, 18 Oct 2023 19:32:09 -0400 (EDT)
In-Reply-To: <86jzrjvohz.fsf@mail.linkov.net>
X-SG-EID: =?us-ascii?Q?GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cO?=
 =?us-ascii?Q?rI4e0V+MFZgakz9Re5a6=2FCglOvsAbX1dri0ph3Q?=
 =?us-ascii?Q?6U9+8X3dRQyRGHUBXnqvPUd=2Ftt9bpny8xAaISiu?=
 =?us-ascii?Q?Y6AmpEIaQOVvZ+KGROgHn5PMhpiMdhSCXPOGx52?=
 =?us-ascii?Q?Nzhp55=2FwidtaRarHMNJNLRWN4VeSPKGmq3iJR5z?=
 =?us-ascii?Q?BfKTmezZPIkMEZK=2FkpK7xxLiDvRCbHX2nN5Z=2Fj?=
X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q==
Received-SPF: pass client-ip=149.72.154.232;
 envelope-from=bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com;
 helo=s.wrqvwxzv.outbound-mail.sendgrid.net
X-Spam_score_int: -7
X-Spam_score: -0.8
X-Spam_bar: /
X-Spam_report: (-0.8 / 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,
 RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001 autolearn=no 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:311563
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/311563>

Juri Linkov <juri@linkov.net> writes:
>>>>>> 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.

Yes, but that's something the user explicitly chooses to do.  (as long
as we don't preselect completions, which (notwithstanding my patch which
does that) I don't think we should do)

And even if they highlight a candidate, they can always unhighlight by
running minibuffer-completion-help (? or M-?) again.

That's a big advantage we have over fido-mode and icomplete, which lets
us avoid this class of problems: We have a way to represent the state
where no candidate is selected/highlighted.