GNU bug report logs - #40625
28.0.50; fido-mode cannot match candidates containing a space

Previous Next

Package: emacs;

Reported by: Omar Antolín Camarena <omar <at> matem.unam.mx>

Date: Tue, 14 Apr 2020 16:02:01 UTC

Severity: normal

Found in version 28.0.50

Done: João Távora <joaotavora <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Omar Antolín Camarena <omar <at> matem.unam.mx>, 40625 <at> debbugs.gnu.org
Subject: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
Date: Wed, 15 Apr 2020 16:46:41 +0100
[Message part 1 (text/plain, inline)]
Found these two commits:

commit 6d4d00c63417e3479e978a373f252b9f2709ce39
Author: João Távora <joaotavora <at> gmail.com>
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 <thierry.volpiatto <at> gmail.com>
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ão

On Wed, Apr 15, 2020 at 1:04 AM João Távora <joaotavora <at> gmail.com> wrote:

> This is likely the flex completion style, not fido-mode itself.
>
> I'll look into it.
>
> João
>
> On Wed, Apr 15, 2020, 00:06 Dmitry Gutov <dgutov <at> yandex.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ín 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 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]" (from there I
>> can press RET to open the file, this bug report is about the "[No matches]"
>> 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 type
>> "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 space
>> in it. I have a "Date input format" entry from coreutils, for example. Use
>> `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 one
>> 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 run).
>> It uses `backward-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 ()
>> >    "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.:)
>>
>>

-- 
João Távora
[Message part 2 (text/html, inline)]

This bug report was last modified 5 years and 73 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.