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 wrote: > Found these two commits: > > commit 6d4d00c63417e3479e978a373f252b9f2709ce39 > Author: João Távora > 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ão > > On Wed, Apr 15, 2020 at 1:04 AM João Távora 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 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