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: Wed, 5 Feb 2020 18:12:40 +0000 Message-ID: References: <288610218.111246.1578330546916@office.mailbox.org> <51d12435-274b-be14-95b8-f790804f1a61@yandex.ru> <157c6af1-c900-188d-490c-4f48ea17da3d@yandex.ru> <5dc9535d-9b2f-56f1-2e63-b75ff3aaaf55@yandex.ru> <9da3ee1b-7315-41d2-192b-9db470d50ba4@yandex.ru> <83blqik9wv.fsf@gnu.org> <838slhglog.fsf@gnu.org> <21dc455e-b56e-3971-86f2-4773a57be64b@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d619c2059dd81a8c" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="67906"; 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 Wed Feb 05 19: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 1izPAo-000HWM-UH for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Feb 2020 19:13:15 +0100 Original-Received: from localhost ([::1]:54754 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izPAo-0000V8-1B for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Feb 2020 13:13:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40985) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izPAd-0000RF-Om for bug-gnu-emacs@gnu.org; Wed, 05 Feb 2020 13:13:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izPAc-0000cL-6f for bug-gnu-emacs@gnu.org; Wed, 05 Feb 2020 13:13:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40723) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1izPAc-0000bB-3H for bug-gnu-emacs@gnu.org; Wed, 05 Feb 2020 13:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1izPAb-0002BR-Tb for bug-gnu-emacs@gnu.org; Wed, 05 Feb 2020 13: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: Wed, 05 Feb 2020 18: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.15809263798385 (code B ref 38992); Wed, 05 Feb 2020 18:13:01 +0000 Original-Received: (at 38992) by debbugs.gnu.org; 5 Feb 2020 18:12:59 +0000 Original-Received: from localhost ([127.0.0.1]:46696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1izPAY-0002BB-Sr for submit@debbugs.gnu.org; Wed, 05 Feb 2020 13:12:59 -0500 Original-Received: from mail-io1-f51.google.com ([209.85.166.51]:39057) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1izPAX-0002Ay-Qd for 38992@debbugs.gnu.org; Wed, 05 Feb 2020 13:12:58 -0500 Original-Received: by mail-io1-f51.google.com with SMTP id c16so3187384ioh.6 for <38992@debbugs.gnu.org>; Wed, 05 Feb 2020 10:12:57 -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=yD1hli2PptLKjYqYmFrQCMMi6JlAPxVSyh9+QPvQpZA=; b=QICMlPotbfVX7x45bnLiQwXsBs2hLxPWBKaEXOcm73NYFg2CxtRiNHvCukyfL/ILjt uaLw93tBLle2nG2HAZDEObTYaACo5TqIvbS2emHNCCX+yHCyZ9dGAPthfD/io45WbMIu kI13Toig+6F24f7Sgb0knMoau06pxRNKHTcAmNrpbsRL9YNEPdvM9pvCHWwtyv8uFAVL QK4njm/4kaFnyywxcSvmX3dW4EPMff2WnB4icEn+vhrJLzCy0ZEhAdjsu6BKRvWJ3D6m UqEvAcSSkv+m7drnD6tRoLivuUpWkEfnIhdNa2GXstrkqd0/jVkP6DxIxijmKG1jmd/J 8eNw== 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=yD1hli2PptLKjYqYmFrQCMMi6JlAPxVSyh9+QPvQpZA=; b=ingpJNzXfZxigz+KVCe90LXUfkiYJSno+4Sk8owzf/2VLJ1AQ02lqyrqBn2fXS7d8J rMdGsfMfbnvDRx856Bv+Eze70jInjvSVbuQvp/8g/wwTBGHKOI1xod3QQfHsotYg7Mid FwZl+uPHkSbhHmxgTcxOw4hkEo56CwUhmF3f8joObE/MlhHfL8fHauOtrASaOhpRz3oQ wK9UZjP77dT2nL0mFSG3lDFmxTKwQwQV82GSThhwx4KcrX4/jVgHUNrUc0hEGz1DLprT /TbliYU9Ru7kvYs6pHYkH3eaZLdpX1pzE+07rGDt8cqIcoz7Hlaq1pMrShlAhgVvP1P1 8DUQ== X-Gm-Message-State: APjAAAW4rP0YebrFzKazReul07fgWWiG2rqOF2bkUXeffJ2ZShcEns/v MH3N7ZbwYYdQnJmqPWxXaChmor/Bl5RxCr0zgG0= X-Google-Smtp-Source: APXvYqxmnvXZsoFQKn9IrvgROAXr88tEOB7JWmmap+n7mKAm3i9vvaEETduP5NcG+I0DgsY5raH1ys4WoitdDEcNio0= X-Received: by 2002:a6b:f214:: with SMTP id q20mr30573139ioh.137.1580926372287; Wed, 05 Feb 2020 10:12:52 -0800 (PST) In-Reply-To: <21dc455e-b56e-3971-86f2-4773a57be64b@yandex.ru> 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:175709 Archived-At: --000000000000d619c2059dd81a8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 5, 2020 at 5:55 PM Dmitry Gutov wrote: > On 05.02.2020 17:27, Jo=C3=A3o T=C3=A1vora wrote: > > With the original problem fixed, Dmitry came to what can be seen as a > > UI deficiency in fido-mode. > > Not exactly. There have been several issues discussed in this report, > and it's really a problem that the user can't easily input something > that completing-read would allow. > So isn't that a UI deficiency in fido-mode? Mind you I'm calling it a deficiency because it can't by definition be a bug. fido-mode is a new thing and I _made_ the spec for it. Of course, I like your suggestions for improvement (as I have showed here). > A new bug report has arrived since: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D39407 It is now > erroneously marked as fixed because it has been merged with this one. We > should undo that. > > The proposed workaround (using M-j) is itself problematic since it > allows you to input whatever even when a match is required. So there are > bug here. > Not sure that is a problem with fido-mode. I think it's reasonable for a completer to bind exit-minibuffer, or to have something that allows it to exit with whatever. exit-minibuffer doesn't honour require-match (maybe it shouldn't) but it is the only such thing that allows any kind of workaround, as far as I am aware. So this isn't a problem with fido-mode. When there is something else to fill this gap -- respect require-match and still allow to exit easily with arbitrary input when that is nil -- then fido-mode will use it. > > After analysing this with Stefan, we arrived > > at the conclusion that it was actually a problem in some longstanding > > minibuffer.el workings. > > Not exactly. At least, icomplete-mode seems to work okay in both of > these respects (please correct me if I'm wrong). > Doesn't icomplete-force-complete-and-exit have a problem, too? I was under the impression that it did, from reading the above thread. > > Maybe, Dmitry, we could revert to the earlier proposal with the new > > variable and somehow deprecate/discourage use of the one you're > > trying to change? That should be safe and bring all the benefits of > > your change, right? > > Yes, we can do that. I'll make the new variable private, so we can rid > of it quickly on master. > Great! Disregard the previous discussion if you want, just do this, and move on. Jo=C3=A3o --000000000000d619c2059dd81a8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 5, 2020 at 5:55 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
On 05.02.202= 0 17:27, Jo=C3=A3o T=C3=A1vora wrote:
> With the original problem fixed, Dmitry came to what can be seen as a<= br> > UI deficiency in fido-mode.

Not exactly. There have been several issues discussed in this report,
and it's really a problem that the user can't easily input somethin= g
that completing-read would allow.

So is= n't that a UI deficiency in fido-mode?=C2=A0 Mind you I'm calling i= t
a deficiency because it can't by definition be a bug.= =C2=A0 fido-mode is a new
thing and I _made_ the spec for it.=C2= =A0 Of course, I like your suggestions
for improvement (as I have= showed here).
=C2=A0
A new bug report has arrived since:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug= =3D39407 It is now
erroneously marked as fixed because it has been merged with this one. We should undo that.

The proposed workaround (using M-j) is itself problematic since it
allows you to input whatever even when a match is required. So there are bug here.

Not sure that is a problem wi= th fido-mode.=C2=A0 I think it's reasonable
for a comple= ter to bind exit-minibuffer, or to have something that
allow= s it to exit with whatever.=C2=A0 exit-minibuffer doesn't honour
require-match (maybe it shouldn't) but it is the only such thi= ng
that allows any kind of workaround, as far as I am aware.=
So this isn't a problem with fido-mode. When there is someth= ing
else to fill this gap -- respect require-match and still allo= w to exit
easily with arbitrary input when that is nil -- th= en fido-mode will use
it.
=C2=A0
> After analysing this with Stefan, we arrived
> at the conclusion that it was actually a problem in some longstanding<= br> > minibuffer.el workings.

Not exactly. At least, icomplete-mode seems to work okay in both of
these respects (please correct me if I'm wrong).
=

Doesn't= icomplete-force-complete-and-exit have a problem, too?=C2=A0 I
<= div class=3D"gmail_quote">was under the impression that it did, from readin= g the above thread.
=C2=A0
> Maybe, Dmitry, we coul= d revert to the earlier proposal with the new
> variable and somehow deprecate/discourage use of the one you're > trying to change?=C2=A0 That should be safe and bring all the benefits= of
> your change, right?

Yes, we can do that. I'll make the new variable private, so we can rid =
of it quickly on master.

Great!=C2=A0= =C2=A0 Disregard the previous discussion if you want, just do this,
and move on.

Jo=C3=A3o

=
--000000000000d619c2059dd81a8c--