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

Previous Next

Full log

Message #17 received at 40625 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>,
 Thierry Volpiatto <thierry.volpiatto <at> gmail.com>, 
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Omar Antolín Camarena <omar <at> matem.unam.mx>,
 40625 <at> debbugs.gnu.org
Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing
 a space
Date: Wed, 15 Apr 2020 17:02:21 +0100

[Message part 1 (text/plain, inline)]

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 <at> gmail.com> wrote:

> 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
>


-- 
João Távora

[Message part 2 (text/html, inline)]

Previous Next

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