From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#38992: 27.0.60; when enabled, fido-mode seems to break vc-git-grep Date: Tue, 21 Jan 2020 08:12:08 +0000 Message-ID: References: <288610218.111246.1578330546916@office.mailbox.org> <7293f6ca-b11d-3d2a-ad71-831135434e75@yandex.ru> <780526337.114357.1578556168662@office.mailbox.org> <944631362.128066.1578605073103@office.mailbox.org> <98df50d8-44fb-448e-e893-f20601f1ca54@yandex.ru> <51d12435-274b-be14-95b8-f790804f1a61@yandex.ru> <157c6af1-c900-188d-490c-4f48ea17da3d@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000099b90e059ca1f72a" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="7016"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 38992@debbugs.gnu.org, Stefan Monnier , waah@yellowfrog.io To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 21 09:13:15 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1itoew-0001kz-GI for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Jan 2020 09:13:14 +0100 Original-Received: from localhost ([::1]:49730 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itoev-0006zh-J0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Jan 2020 03:13:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50684) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itoem-0006zK-Kp for bug-gnu-emacs@gnu.org; Tue, 21 Jan 2020 03:13:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1itoek-0006ru-5B for bug-gnu-emacs@gnu.org; Tue, 21 Jan 2020 03:13:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40471) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1itoek-0006ri-0s for bug-gnu-emacs@gnu.org; Tue, 21 Jan 2020 03:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1itoej-0002GE-SJ for bug-gnu-emacs@gnu.org; Tue, 21 Jan 2020 03:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Jan 2020 08:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38992 X-GNU-PR-Package: emacs Original-Received: via spool by 38992-submit@debbugs.gnu.org id=B38992.15795943508651 (code B ref 38992); Tue, 21 Jan 2020 08:13:01 +0000 Original-Received: (at 38992) by debbugs.gnu.org; 21 Jan 2020 08:12:30 +0000 Original-Received: from localhost ([127.0.0.1]:46444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1itoeD-0002FT-JN for submit@debbugs.gnu.org; Tue, 21 Jan 2020 03:12:29 -0500 Original-Received: from mail-il1-f175.google.com ([209.85.166.175]:36033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1itoeB-0002FD-1s for 38992@debbugs.gnu.org; Tue, 21 Jan 2020 03:12:28 -0500 Original-Received: by mail-il1-f175.google.com with SMTP id b15so1686842iln.3 for <38992@debbugs.gnu.org>; Tue, 21 Jan 2020 00:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8eZO244/QVbTA1mbUcBIi/XCwVpjSbTwoH0iMQHgpUk=; b=alSPFSODSwGTpmVobWK8aXmlJVPR6O7TdI8P6QsGvXBPyC2kc1Su4OuEKIGskhLF/k XljIwLSSnh5UxxkPIg3uznDJU2Oce3s1BBgoYKzAxJ6tf66pOL5XcSPIzpb8QPSuktbk NDPODPqUdpoOrU0qQ5dAPuVJsRYm8BjmVOjcyt6gJDvG2V9PsuKCzyHFBvhgyBRyFEJE Eg0PeTBavnWbvIB2t72DxT23zGbql1MKUVrzY+19qCe6aMbAM0i9oOcal3H0gFmKn5zn kAsQ2bRu4pZZKZm698UQe5sS/CM2rhk/V3YVbkzRPAcEwLPztGY1TGskhZRiNDTRcu4G BwBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8eZO244/QVbTA1mbUcBIi/XCwVpjSbTwoH0iMQHgpUk=; b=MzDjHiO+NrkIXqRGQdvrna2HnHz0SqAbrxupsTMGkqVXxJYy/eMuvbfTkA0PYkQ4Fu VVAAq+7RPImSJZHKVLAiIh1t9HmnC3WSoDeLLz1lUNpoGO+TdaETmpX8161Ae1lk+Hpb D13nA/Uk4ysOGNhlnwi9Z/1c9jhtKNQFuFRcuhIC0HshKlC7ERnrIa2djKtLmDNCdxwh MUZaQ53rRI9Ipw/hQZ+yNS0zHNctWzZI65cIfLUX1Mm3UgWUpEwIOGS0oMcf9+uOgvC5 apiqPaY9Qgt4LwpR9PudgNiiGnRkjHJcSlIM9OArG9S00iaorG1OeUiW5GbGlGKPsodv R9XQ== X-Gm-Message-State: APjAAAUk9WvKJjgpGRCKmtS1mPG6zS/tXapjm9VtMPiAE8y3EXbVbA66 gqs9BGNddL/+MiF5b6JaCljlrsFCuPPD1uRU/48= X-Google-Smtp-Source: APXvYqzYx4qU2SV603CAK0scM/ImABj7MY3EuOJhCo8MG+oxP3kBAGgHeCzRTz3QDkKZcgM7iS7/P9Ib6kb9ukKyq4U= X-Received: by 2002:a92:884e:: with SMTP id h75mr2669351ild.199.1579594341266; Tue, 21 Jan 2020 00:12:21 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:174984 Archived-At: --00000000000099b90e059ca1f72a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2020, 23:56 Dmitry Gutov wrote: > On 21.01.2020 2:04, Stefan Monnier wrote,: > > The `minibuffer-force-complete` call is the one which actually selects > > the "first candidate" from the list of completions, so I do think it's > necessary. > > Oh. Right. Somehow I hadn't tested a scenario where this would matter. > Phew! :) > > IIUC the bug under discussion is related to the `required` argument of > > `completing-read` (and to `minibuffer-completion-confirm`). > > Right. > > > If `required` was nil (as is the case in `grep-read-files` which > > I believe is the relevant function here), then when `test-completion` > > fails, we should probably just call `exit-minibuffer` (rather than tell > > the user that they should do that). > > Ido added an extra prompt in situations like this, I think. What you're > saying was my first suggestion, but it would require a more invasive > change. > As I said, you can try it out, maybe with a new binding for RET. Please don't add an extra prompt. And icomplete-force-complete-and-exit, as implemented, calls > minibuffer-force-complete-and-exit which doesn't seem to care (or know?) > that REQUIRED was nil. If you have a particular change in mind, I'd > happily try a patch. > > BTW, I now see that my patch changes a function belonging to icomplete, > whileas the intention was only to fix fido-mode's behavior. Do you think > the change fits icomplete-mode as well? > > > The problem here is probably caused by the fact that fido-mode arranges > > for `minibuffer-force-complete` to choose the *default* rather than to > > choose a candidate from the completion table. It's rare for > > a completion table to return candidates that don't pass > > `test-completion` (tho it's by not impossible nor incorrect), but it's > > much less rare for the default not to pass `test-completion`. > > Um, not sure I understand. The problem here is that typing 'all' (unless > it matches some of the local files names) or '*.el' and typing RET > doesn't work. minibuffer-force-complete tries to choose a completion > from the table, and when it can't, we get the "Incomplete" message. > Though if it can (there's a matching filename), it ends up worse for the > user, in this particular situation. > Dmitry, I wrestled a lot with the the "default" case among others. I wish I had written tests for it but it is quite hard. When experimenting with this at least try: - pressing ret quickly before the first completions appear, with a default, like in c-h f. There should be no wait. - same but slowly, the default should be on top. - m-x man on an word that doesn't perfectly match the candidates, like "read" (I think). Observe differences before and after. Also sorting matters, obviously. Fido mode does some sorting itself to move the default to the top position, I think. Jo=C3=A3o > --00000000000099b90e059ca1f72a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jan 20, 2020, 23:56 Dmitry Gutov <dgutov@yandex.r= u> wrote:
On 21.01.2020 2:04= , Stefan Monnier wrote,:
> The `minibuffer-force-complete` call is the one which actually selects=
> the "first candidate" from the list of completions, so I do = think it's necessary.

Oh. Right. Somehow I hadn't tested a scenario where this would matter.<= br>

P= hew! :)


> IIUC the bug under discussion is related to the `required` argument of=
> `completing-read` (and to `minibuffer-completion-confirm`).

Right.

> If `required` was nil (as is the case in `grep-read-files` which
> I believe is the relevant function here), then when `test-completion`<= br> > fails, we should probably just call `exit-minibuffer` (rather than tel= l
> the user that they should do that).

Ido added an extra prompt in situations like this, I think. What you're=
saying was my first suggestion, but it would require a more invasive change= .

As I said, you can try it out, maybe with a new binding for RET. Please do= n't add an extra prompt.

And icomplete-force-complete-and-exit, as implemented, calls
minibuffer-force-complete-and-exit which doesn't seem to care (or know?= )
that REQUIRED was nil. If you have a particular change in mind, I'd happily try a patch.

BTW, I now see that my patch changes a function belonging to icomplete, whileas the intention was only to fix fido-mode's behavior. Do you thin= k
the change fits icomplete-mode as well?

> The problem here is probably caused by the fact that fido-mode arrange= s
> for `minibuffer-force-complete` to choose the *default* rather than to=
> choose a candidate from the completion table.=C2=A0 It's rare for<= br> > a completion table to return candidates that don't pass
> `test-completion` (tho it's by not impossible nor incorrect), but = it's
> much less rare for the default not to pass `test-completion`.

Um, not sure I understand. The problem here is that typing 'all' (u= nless
it matches some of the local files names) or '*.el' and typing RET =
doesn't work. minibuffer-force-complete tries to choose a completion from the table, and when it can't, we get the "Incomplete" me= ssage.
Though if it can (there's a matching filename), it ends up worse for th= e
user, in this particular situation.

Dmitry, I wrestled a lot with the the &q= uot;default" case among others. I wish I had written tests for it but = it is quite hard. When experimenting with this at least try:

- pressing ret quickly before the fir= st completions appear, with a default, like in c-h f. There should be no wa= it.
- same but slowly, the default should be on top.=
- m-x man on an word that doesn't perfectly mat= ch the candidates, like "read" (I think).
=
Observe differences before and after. Also sort= ing matters, obviously. Fido mode does some sorting itself to move the defa= ult to the top position, I think.

Jo=C3=A3o
--00000000000099b90e059ca1f72a--