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#40625: 28.0.50; fido-mode cannot match candidates containing a space Date: Wed, 15 Apr 2020 16:46:41 +0100 Message-ID: References: <87lfmy6oq7.fsf@matem.unam.mx> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ae297d05a356396d" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="63425"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Omar =?UTF-8?Q?Antol=C3=ADn?= Camarena , 40625@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 15 17:48: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 1jOkGs-000GMi-Sm for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Apr 2020 17:48:14 +0200 Original-Received: from localhost ([::1]:52012 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOkGr-0002Sj-Uh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Apr 2020 11:48:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58521) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOkGj-0002Pv-BC for bug-gnu-emacs@gnu.org; Wed, 15 Apr 2020 11:48:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jOkGh-0006Yc-9f for bug-gnu-emacs@gnu.org; Wed, 15 Apr 2020 11:48:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53640) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jOkGg-0006YD-KU for bug-gnu-emacs@gnu.org; Wed, 15 Apr 2020 11:48:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jOkGg-0004UF-Gu for bug-gnu-emacs@gnu.org; Wed, 15 Apr 2020 11:48:02 -0400 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, 15 Apr 2020 15:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40625 X-GNU-PR-Package: emacs Original-Received: via spool by 40625-submit@debbugs.gnu.org id=B40625.158696562217169 (code B ref 40625); Wed, 15 Apr 2020 15:48:02 +0000 Original-Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 15:47:02 +0000 Original-Received: from localhost ([127.0.0.1]:36953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOkFh-0004Sq-O4 for submit@debbugs.gnu.org; Wed, 15 Apr 2020 11:47:02 -0400 Original-Received: from mail-io1-f42.google.com ([209.85.166.42]:33531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOkFf-0004SL-IX for 40625@debbugs.gnu.org; Wed, 15 Apr 2020 11:47:00 -0400 Original-Received: by mail-io1-f42.google.com with SMTP id o127so17653027iof.0 for <40625@debbugs.gnu.org>; Wed, 15 Apr 2020 08:46:59 -0700 (PDT) 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=/NcASnE1y2lU7m2SQqDSvRFH8BtP0XpczhbNsMKxlM4=; b=QaQGrzSHPcoodycoKOdSjDT+nmJ4TCADVHtj32tP/J1zr8e2JPxaM6do6y6g+LYHaO w/9UDyE+q0SQDTtDwuANyj/8AxtnBtUwsu5EO0/lYWIMk8M+b7XNyevjgdoDn5T6OVdX 9EDBspezgg55ygTjqrKprnGvcIUW2gpRsgfWvu2V9nQWXQDJo72f+mu+guZDplQhfZwm OKVzn9GXcers8O/NmIOZR5blLMA42n/6sIHlD7twiva7jwvIvN3hW2jU/GDFTqx1TVKK SF0x/olnr8c4azb5Q6YF9e+HlhGgKqJMmqFbUD82bBbE04adYIxc70az90/NV18yZmmS 5yiA== 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=/NcASnE1y2lU7m2SQqDSvRFH8BtP0XpczhbNsMKxlM4=; b=LAHb7Fb6c31bL30C0gP6TlmW3xPgv52E+AJDthqdtEPHDZyj08lq3O775jjrm4kkEB 2cHjA2FAzTImhYrz4WXSKc6Ttvhi7b8SNTSDeAKKOltnZRutGORChpPx23NQMn0F5LsB gTyBEGusXz0eNdBmAMimWRYiDYC4nRjn+2mfMB1D5ZXcTOa9qIfJL40FSScNtI23fQoZ NUrTBRSPIoVrGL8Z55CEe+Vvr3F53btOp/5mBJ87RfatDaUe9rGSqzjLedO/vSvQGfyr x8ot5o4FLjQ5Xv29L2Fw8/leZtJONsIAQ57/Io6jj89nHxDi4KfpcXGlx4v4kAKwA/gA cKIw== X-Gm-Message-State: AGi0PuZAA02hriuZdGQeuFcniV7AI/utcJFvT45Zxsy4oHxokimKwfEt jC13QWmPI/ZNqYcv3AgtLhSMF56e4PdQ8u6Xb6g= X-Google-Smtp-Source: APiQypJdd3cu7Pch6BVsXbI3KDIMZgF0KLEjzNtXCet+gqg9sxPfTcdVg/Y1UmRurgGasL6J872H83AYZBJDkHsVwK8= X-Received: by 2002:a02:93cf:: with SMTP id z73mr26715260jah.136.1586965613782; Wed, 15 Apr 2020 08:46:53 -0700 (PDT) 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:178405 Archived-At: --000000000000ae297d05a356396d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Found these two commits: commit 6d4d00c63417e3479e978a373f252b9f2709ce39 Author: Jo=C3=A3o T=C3=A1vora Date: Sat Nov 23 00:30:49 2019 +0000 * lisp/minibuffer.el (completion-flex-nospace): Default to t. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3499,4 +3499,4 @@ -(defcustom completion-flex-nospace nil - "Make flex style fail when a space is found in pattern." +(defcustom completion-flex-nospace t + "Non-nil if `flex' completion rejects spaces in search pattern." :version "27.1" :type 'boolean) commit 5a62c4b49ca1ac45d576f55d266750b7d1d6668a Author: Thierry Volpiatto Date: Thu Nov 21 20:41:19 2019 +0100 Add new variable to prevent flex completion style matching spaces. This allows flex style working smoothly with other styles like helm using spaces. * lisp/minibuffer.el (completion-flex-nospace): New user var. (completion-flex-try-completion): Use it. (completion-flex-all-completions): Same. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3497,0 +3497,4 @@ +(defcustom completion-flex-nospace nil + "Make flex style fail when a space is found in pattern." + :version "27.1" + :type 'boolean) I honestly _don't_ remember discussing this (says a lot for for the state of my brain lately). But it seems reasonable for users that wish to use spaces to set this to nil, so hopefully the emergency is resolved. I don't know what prompted me to default it to t, but I wouldn't be very quick in reverting it. That said, the "rejection" of space should be handled differently: I agree this is confusing. Jo=C3=A3o On Wed, Apr 15, 2020 at 1:04 AM Jo=C3=A3o T=C3=A1vora wrote: > This is likely the flex completion style, not fido-mode itself. > > I'll look into it. > > Jo=C3=A3o > > On Wed, Apr 15, 2020, 00:06 Dmitry Gutov wrote: > >> Thanks for the report. >> >> I can reproduce all three. >> >> FWIW, the "bare" icomplete-mode works fine in these cases. >> >> On 14.04.2020 19:01, Omar Antol=C3=ADn Camarena wrote: >> > Here are 3 scenarios I tested with fido-mode starting from emacs -Q >> (all of these work perfectly with icomplete): >> > >> > 1. Files with spaces. >> > >> > Run emacs -Q and use `M-x fido-mode' to activate fido-mode. >> > Create a file with a space in the name. Use find-file to try to open >> it. As soon as you have a space in the minibuffer, it says "[No matches]= ". >> > >> > For example, I created a file called "one two", and no other file in m= y >> home directory starts with "one". In find-file when I type "one" I see t= he >> expected result: "~/one[ two] [Matched]". >> > >> > If I press TAB to complete I get "one two [No matches]" (from there I >> can press RET to open the file, this bug report is about the "[No matche= s]" >> which is >> > clearly wrong). >> > >> > If after entering "one" I press space, I get "one [No matches]", that >> it, I no longer get offered the "one two" completion. >> > >> > 2. Directories with spaces. >> > >> > In emacs -Q use `M-x fido-mode' to activate fido-mode. >> > Create a directory with a space in the name. I created a directory >> called "a b" and put a file called "c" inside. If I run find-file and ty= pe >> "a " (that's a followed by space), I see "~/a [No matches]". Even typing= "a >> b/" gives me "~/a b/ [No matches]", and neither TAB nor C-M-i >> (icomplete-force-complete) will complete the file "~/a b/c". >> > >> > 3. Menu entries in an info buffer. >> > >> > In emacs -Q use `M-x fido-mode' to activate fido-mode. >> > Use `C-h i' to open the main info directory, pick an entry with a spac= e >> in it. I have a "Date input format" entry from coreutils, for example. U= se >> `m' (bound to Info-menu) and type "Date". fido-mode does offer me the >> relevant completions, and in my case, "Date input format" is the only on= e >> where "Date" is followed by a space. If I type the space nothing happens >> (space is bound to minibuffer-complete-word), no space is entered, the >> candidates don't change. Pressing space again pops up the completions >> buffer. >> > >> > If I use `C-q SPC` to insert a literal space, I get "Date (No >> matches)". >> > >> > If I skip the space and keep typing "inpu", it matches "Date input >> format", but pressing TAB to complete it to the full "Date input format" >> again says "(No matches)" ---pressing RET will however open the correct >> manual. >> > >> > ---------- >> > >> > This was initially meant to be a bug report for >> `icomplete-fido-backward-updir', whose source code I read (but didn't ru= n). >> It uses `backward-kill-sexp', which means it won't fully go up a directo= ry >> if it has spaces in it. I suggest replacing (backward-kill-sexp 1) with >> (zap-up-to-char -1 ?/), as follows: >> > >> > (defun icomplete-fido-backward-updir () >> > "Delete char before or go up directory, like `ido-mode'." >> > (interactive) >> > (if (and (eq (char-before) ?/) >> > (eq (icomplete--category) 'file)) >> > (zap-up-to-char -1 ?/) >> > (call-interactively 'backward-delete-char))) >> > >> > Before submitting that report I decided to test fido-mode and >> discovered it has more fundamental problems with spaces than that.:) >> >> --=20 Jo=C3=A3o T=C3=A1vora --000000000000ae297d05a356396d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Found these two commits:

com= mit 6d4d00c63417e3479e978a373f252b9f2709ce39
Author: Jo=C3=A3o T=C3=A1vo= ra <joaotavora@gmail.com>=
Date: =C2=A0 Sat Nov 23 00:30:49 2019 +0000

=C2=A0 =C2=A0 * lisp= /minibuffer.el (completion-flex-nospace): Default to t.

diff --git a= /lisp/minibuffer.el b/lisp/minibuffer.el
--- a/lisp/minibuffer.el
+++= b/lisp/minibuffer.el
@@ -3499,4 +3499,4 @@
-(defcustom completion-fl= ex-nospace nil
- =C2=A0"Make flex style fail when a space is found = in pattern."
+(defcustom completion-flex-nospace t
+ =C2=A0"= ;Non-nil if `flex' completion rejects spaces in search pattern."=C2=A0 =C2=A0:version "27.1"
=C2=A0 =C2=A0:type 'boolean= )

commit 5a62c4b49ca1ac45d576f55d266750b7d1d6668a
Author: Thierry= Volpiatto <thierry.volpi= atto@gmail.com>
Date: =C2=A0 Thu Nov 21 20:41:19 2019 +0100
=C2=A0 =C2=A0 Add new variable to prevent flex completion style
=C2=A0= =C2=A0
=C2=A0 =C2=A0 matching spaces.=C2=A0 This allows flex style wor= king smoothly with other
=C2=A0 =C2=A0 styles like helm using spaces.=C2=A0 =C2=A0
=C2=A0 =C2=A0 * lisp/minibuffer.el (completion-flex-nosp= ace): New user var.
=C2=A0 =C2=A0 (completion-flex-try-completion): Use = it.
=C2=A0 =C2=A0 (completion-flex-all-completions): Same.

diff -= -git a/lisp/minibuffer.el b/lisp/minibuffer.el
--- a/lisp/minibuffer.el<= br>+++ b/lisp/minibuffer.el
@@ -3497,0 +3497,4 @@
+(defcustom complet= ion-flex-nospace nil
+ =C2=A0"Make flex style fail when a space is = found in pattern."
+ =C2=A0:version "27.1"
+ =C2=A0:ty= pe 'boolean)

I honestly _don't_ remember d= iscussing this (says a lot for for
the state of my brain lat= ely).

But it seems reasonable for users that = wish to use spaces to
set this to nil, so hopefully the emer= gency is resolved.=C2=A0 I don't
know what prompted me to def= ault it to t, but I wouldn't be
very quick in reverting it. T= hat said, the "rejection" of space
should be handled di= fferently: I agree this is confusing.

Jo=C3=A3o

On Wed, Apr 15, 2020 at 1:04 AM Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> wrote:
=
This is= likely the flex completion style, not fido-mode itself.
<= br>
I'll look into it.
Jo=C3=A3o

On Wed, Apr 15, 2020, 00:06 Dmitry= Gutov <dgutov@yan= dex.ru> wrote:
Thanks for the report.

I can reproduce all three.

FWIW, the "bare" icomplete-mode works fine in these cases.

On 14.04.2020 19:01, Omar Antol=C3=ADn Camarena wrote:
> Here are 3 scenarios I tested with fido-mode starting from emacs -Q (a= ll of these work perfectly with icomplete):
>
> 1. Files with spaces.
>
> Run emacs -Q and use `M-x fido-mode' to activate fido-mode.
> Create a file with a space in the name. Use find-file to try to open i= t. As soon as you have a space in the minibuffer, it says "[No matches= ]".
>
> For example, I created a file called "one two", and no other= file in my home directory starts with "one". In find-file when I= type "one" I see the expected result: "~/one[ two] [Matched= ]".
>
> If I press TAB to complete I get "one two [No matches]" (fro= m there I can press RET to open the file, this bug report is about the &quo= t;[No matches]" which is
> clearly wrong).
>
> If after entering "one" I press space, I get "one=C2=A0= [No matches]", that it, I no longer get offered the "one two&quo= t; completion.
>
> 2. Directories with spaces.
>
> In emacs -Q use `M-x fido-mode' to activate fido-mode.
> Create a directory with a space in the name. I created a directory cal= led "a b" and put a file called "c" inside. If I run fi= nd-file and type "a " (that's a followed by space), I see &qu= ot;~/a [No matches]". Even typing "a b/" gives me "~/a = b/=C2=A0 [No matches]", and neither TAB nor C-M-i (icomplete-force-com= plete) will complete the file "~/a b/c".
>
> 3. Menu entries in an info buffer.
>
> In emacs -Q use `M-x fido-mode' to activate fido-mode.
> Use `C-h i' to open the main info directory, pick an entry with a = space in it. I have a "Date input format" entry from coreutils, f= or example. Use `m' (bound to Info-menu) and type "Date". fid= o-mode does offer me the relevant completions, and in my case, "Date i= nput format" is the only one where "Date" is followed by a s= pace. If I type the space nothing happens (space is bound to minibuffer-com= plete-word), no space is entered, the candidates don't change. Pressing= space again pops up the completions buffer.
>
> If I use `C-q SPC` to insert a literal space, I get "Date=C2=A0 (= No matches)".
>
> If I skip the space and keep typing "inpu", it matches "= ;Date input format", but pressing TAB to complete it to the full "= ;Date input format" again says "(No matches)" ---pressing RE= T will however open the correct manual.
>
> ----------
>
> This was initially meant to be a bug report for `icomplete-fido-backwa= rd-updir', whose source code I read (but didn't run). It uses `back= ward-kill-sexp', which means it won't fully go up a directory if it= has spaces in it. I suggest replacing (backward-kill-sexp 1) with (zap-up-= to-char -1 ?/), as follows:
>
> (defun icomplete-fido-backward-updir ()
>=C2=A0 =C2=A0 "Delete char before or go up directory, like `ido-mo= de'."
>=C2=A0 =C2=A0 (interactive)
>=C2=A0 =C2=A0 (if (and (eq (char-before) ?/)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(eq (icomplete--categor= y) 'file))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (zap-up-to-char -1 ?/)
>=C2=A0 =C2=A0 =C2=A0 (call-interactively 'backward-delete-char))) >
> Before submitting that report I decided to test fido-mode and discover= ed it has more fundamental problems with spaces than that.:)



--
Jo=C3=A3o T=C3=A1vora
--000000000000ae297d05a356396d--