bug#40625: 28.0.50; fido-mode cannot match candidates containing a space

[João Távora]

Right, here's the origin of the completion-flex-nospace var. 

More people were involved, seems I didn't just pull this out

of thin air :-).

https://github.com/emacs-helm/helm/issues/2165#issuecomment-557155152

The purpose of that variable is to be set to t when the user wants

to add other completion styles after `flex' in the completion-styles

variable.  It doesn't make much sense for fido-mode, because

fido-mode only uses one style by definition.  So maybe fthe

fido-mode UI should force it to nil, much like Helm UI forces

it to t.

Anyway, I defaulted it to t because of this reasoning:

https://github.com/emacs-helm/helm/issues/2165#issuecomment-557272851

I seem to have proposed to set it to t so that users could more

easily compose flex with their special helm styles.  But then

Thierry said those styles are Helm-UI specific anyway and

the discussion to make them available to more Emacs users

never unfolded.  So, I think the rationale for having

completion-flex-nospace default to t is mostly gone.  I mean,

users that do come up with some fancy-shmancy style

can set them to t themselves, right?

So I propose we default it to nil. What do you guys think?

Also, because flex is a new thing in Emacs 27 anyway,

I propose we do it in the emacs-27 branch.  Eli?

João

On Wed, Apr 15, 2020 at 4:46 PM João Távora <joaotavora@gmail.com> wrote:

Found these two commits:

commit 6d4d00c63417e3479e978a373f252b9f2709ce39
Author: João Távora <joaotavora@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@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@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@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

--

João Távora