From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 14 12:01:48 2020 Received: (at submit) by debbugs.gnu.org; 14 Apr 2020 16:01:49 +0000 Received: from localhost ([127.0.0.1]:34568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOO0R-0000SU-Tp for submit@debbugs.gnu.org; Tue, 14 Apr 2020 12:01:48 -0400 Received: from lists.gnu.org ([209.51.188.17]:32925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOO0P-0000SJ-Iq for submit@debbugs.gnu.org; Tue, 14 Apr 2020 12:01:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47504) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOO0G-0007Ey-Tm for bug-gnu-emacs@gnu.org; Tue, 14 Apr 2020 12:01:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jOO08-00087B-FH for bug-gnu-emacs@gnu.org; Tue, 14 Apr 2020 12:01:36 -0400 Received: from gauss.matem.unam.mx ([132.248.17.1]:33427) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jOO08-00085E-45 for bug-gnu-emacs@gnu.org; Tue, 14 Apr 2020 12:01:28 -0400 Received: from penguin (unknown [201.103.213.190]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: omar) by gauss.matem.unam.mx (Postfix) with ESMTP id 596E354220 for ; Tue, 14 Apr 2020 11:01:23 -0500 (CDT) From: =?utf-8?Q?Omar_Antol=C3=ADn_Camarena?= To: bug-gnu-emacs@gnu.org Subject: 28.0.50; fido-mode cannot match candidates containing a space Date: Tue, 14 Apr 2020 11:01:20 -0500 Message-ID: <87lfmy6oq7.fsf@matem.unam.mx> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.248.17.1 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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. :) In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11, cairo version 1.14.8) of 2020-04-08, unofficial emacs-snapshot build: http://emacs.ganneff.de/, git commit 1aeb1819353418ebed635f18a009048700ba1ad0 built on runner-d40f5ff3-project-26-concurrent-0 Repository revision: dbd4101f13a60dfe6e444db76212c8586aff73a9 Repository branch: HEAD Windowing system distributor 'The X.Org Foundation', version 11.0.12001000 System Description: Debian GNU/Linux 9 (stretch) Recent messages: Searching for doc string error...87% Checkdoc: Done. [2 times] Searching for doc string error...87% Checkdoc: Done. [2 times] Auto-saving...done Mark set Saving file /home/omarantolin/my-emacs-packages/placeholder/placeholder.el... Wrote /home/omarantolin/my-emacs-packages/placeholder/placeholder.el Quit [2 times] emacs -Q: finished. [2 times] Configured using: 'configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/28.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.0.50/site-lisp:/usr/share/emacs/site-lisp --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/28.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.0.50/site-lisp:/usr/share/emacs/site-lisp --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -fdebug-prefix-map=/builds/joerg/emacs/stretch_amd64/emacs-snapshot-20200408+emacs-27.0.90-654-g1aeb181935=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro' Configured features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS PDUMPER LCMS2 GMP Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: shell-dirtrack-mode: t flimenu-global-mode: t flimenu-mode: t goto-address-prog-mode: t show-paren-mode: t electric-pair-mode: t beginend-global-mode: t beginend-prog-mode: t global-dot-mode: t dot-mode: t global-gobble-whitespace-mode: t icomplete-vertical-mode: t icomplete-mode: t minibuffer-electric-default-mode: t minibuffer-depth-indicate-mode: t gcmh-mode: t override-global-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: /usr/share/emacs/28.0.50/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox hides /usr/share/emacs/28.0.50/lisp/org/ox /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-texinfo hides /usr/share/emacs/28.0.50/lisp/org/ox-texinfo /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-publish hides /usr/share/emacs/28.0.50/lisp/org/ox-publish /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-org hides /usr/share/emacs/28.0.50/lisp/org/ox-org /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-odt hides /usr/share/emacs/28.0.50/lisp/org/ox-odt /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-md hides /usr/share/emacs/28.0.50/lisp/org/ox-md /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-man hides /usr/share/emacs/28.0.50/lisp/org/ox-man /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-latex hides /usr/share/emacs/28.0.50/lisp/org/ox-latex /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-icalendar hides /usr/share/emacs/28.0.50/lisp/org/ox-icalendar /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-html hides /usr/share/emacs/28.0.50/lisp/org/ox-html /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-beamer hides /usr/share/emacs/28.0.50/lisp/org/ox-beamer /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ox-ascii hides /usr/share/emacs/28.0.50/lisp/org/ox-ascii /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org hides /usr/share/emacs/28.0.50/lisp/org/org /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-version hides /usr/share/emacs/28.0.50/lisp/org/org-version /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-timer hides /usr/share/emacs/28.0.50/lisp/org/org-timer /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-tempo hides /usr/share/emacs/28.0.50/lisp/org/org-tempo /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-table hides /usr/share/emacs/28.0.50/lisp/org/org-table /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-src hides /usr/share/emacs/28.0.50/lisp/org/org-src /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-protocol hides /usr/share/emacs/28.0.50/lisp/org/org-protocol /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-plot hides /usr/share/emacs/28.0.50/lisp/org/org-plot /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-pcomplete hides /usr/share/emacs/28.0.50/lisp/org/org-pcomplete /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-num hides /usr/share/emacs/28.0.50/lisp/org/org-num /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-mouse hides /usr/share/emacs/28.0.50/lisp/org/org-mouse /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-mobile hides /usr/share/emacs/28.0.50/lisp/org/org-mobile /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-macs hides /usr/share/emacs/28.0.50/lisp/org/org-macs /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-macro hides /usr/share/emacs/28.0.50/lisp/org/org-macro /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-loaddefs hides /usr/share/emacs/28.0.50/lisp/org/org-loaddefs /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-list hides /usr/share/emacs/28.0.50/lisp/org/org-list /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-lint hides /usr/share/emacs/28.0.50/lisp/org/org-lint /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-keys hides /usr/share/emacs/28.0.50/lisp/org/org-keys /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-install hides /usr/share/emacs/28.0.50/lisp/org/org-install /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-inlinetask hides /usr/share/emacs/28.0.50/lisp/org/org-inlinetask /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-indent hides /usr/share/emacs/28.0.50/lisp/org/org-indent /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-id hides /usr/share/emacs/28.0.50/lisp/org/org-id /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-habit hides /usr/share/emacs/28.0.50/lisp/org/org-habit /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-goto hides /usr/share/emacs/28.0.50/lisp/org/org-goto /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-footnote hides /usr/share/emacs/28.0.50/lisp/org/org-footnote /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-feed hides /usr/share/emacs/28.0.50/lisp/org/org-feed /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-faces hides /usr/share/emacs/28.0.50/lisp/org/org-faces /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-entities hides /usr/share/emacs/28.0.50/lisp/org/org-entities /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-element hides /usr/share/emacs/28.0.50/lisp/org/org-element /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-duration hides /usr/share/emacs/28.0.50/lisp/org/org-duration /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-datetree hides /usr/share/emacs/28.0.50/lisp/org/org-datetree /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-ctags hides /usr/share/emacs/28.0.50/lisp/org/org-ctags /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-crypt hides /usr/share/emacs/28.0.50/lisp/org/org-crypt /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-compat hides /usr/share/emacs/28.0.50/lisp/org/org-compat /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-colview hides /usr/share/emacs/28.0.50/lisp/org/org-colview /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-clock hides /usr/share/emacs/28.0.50/lisp/org/org-clock /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-capture hides /usr/share/emacs/28.0.50/lisp/org/org-capture /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-attach hides /usr/share/emacs/28.0.50/lisp/org/org-attach /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-attach-git hides /usr/share/emacs/28.0.50/lisp/org/org-attach-git /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-archive hides /usr/share/emacs/28.0.50/lisp/org/org-archive /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/org-agenda hides /usr/share/emacs/28.0.50/lisp/org/org-agenda /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol hides /usr/share/emacs/28.0.50/lisp/org/ol /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-w3m hides /usr/share/emacs/28.0.50/lisp/org/ol-w3m /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-rmail hides /usr/share/emacs/28.0.50/lisp/org/ol-rmail /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-mhe hides /usr/share/emacs/28.0.50/lisp/org/ol-mhe /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-irc hides /usr/share/emacs/28.0.50/lisp/org/ol-irc /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-info hides /usr/share/emacs/28.0.50/lisp/org/ol-info /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-gnus hides /usr/share/emacs/28.0.50/lisp/org/ol-gnus /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-eww hides /usr/share/emacs/28.0.50/lisp/org/ol-eww /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-eshell hides /usr/share/emacs/28.0.50/lisp/org/ol-eshell /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-docview hides /usr/share/emacs/28.0.50/lisp/org/ol-docview /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-bibtex hides /usr/share/emacs/28.0.50/lisp/org/ol-bibtex /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ol-bbdb hides /usr/share/emacs/28.0.50/lisp/org/ol-bbdb /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob hides /usr/share/emacs/28.0.50/lisp/org/ob /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-vala hides /usr/share/emacs/28.0.50/lisp/org/ob-vala /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-tangle hides /usr/share/emacs/28.0.50/lisp/org/ob-tangle /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-table hides /usr/share/emacs/28.0.50/lisp/org/ob-table /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-stan hides /usr/share/emacs/28.0.50/lisp/org/ob-stan /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-sqlite hides /usr/share/emacs/28.0.50/lisp/org/ob-sqlite /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-sql hides /usr/share/emacs/28.0.50/lisp/org/ob-sql /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-shen hides /usr/share/emacs/28.0.50/lisp/org/ob-shen /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-shell hides /usr/share/emacs/28.0.50/lisp/org/ob-shell /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-sed hides /usr/share/emacs/28.0.50/lisp/org/ob-sed /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-screen hides /usr/share/emacs/28.0.50/lisp/org/ob-screen /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-scheme hides /usr/share/emacs/28.0.50/lisp/org/ob-scheme /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-sass hides /usr/share/emacs/28.0.50/lisp/org/ob-sass /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-ruby hides /usr/share/emacs/28.0.50/lisp/org/ob-ruby /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-ref hides /usr/share/emacs/28.0.50/lisp/org/ob-ref /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-python hides /usr/share/emacs/28.0.50/lisp/org/ob-python /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-processing hides /usr/share/emacs/28.0.50/lisp/org/ob-processing /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-plantuml hides /usr/share/emacs/28.0.50/lisp/org/ob-plantuml /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-picolisp hides /usr/share/emacs/28.0.50/lisp/org/ob-picolisp /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-perl hides /usr/share/emacs/28.0.50/lisp/org/ob-perl /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-org hides /usr/share/emacs/28.0.50/lisp/org/ob-org /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-octave hides /usr/share/emacs/28.0.50/lisp/org/ob-octave /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-ocaml hides /usr/share/emacs/28.0.50/lisp/org/ob-ocaml /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-mscgen hides /usr/share/emacs/28.0.50/lisp/org/ob-mscgen /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-maxima hides /usr/share/emacs/28.0.50/lisp/org/ob-maxima /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-matlab hides /usr/share/emacs/28.0.50/lisp/org/ob-matlab /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-makefile hides /usr/share/emacs/28.0.50/lisp/org/ob-makefile /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-lua hides /usr/share/emacs/28.0.50/lisp/org/ob-lua /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-lob hides /usr/share/emacs/28.0.50/lisp/org/ob-lob /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-lisp hides /usr/share/emacs/28.0.50/lisp/org/ob-lisp /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-lilypond hides /usr/share/emacs/28.0.50/lisp/org/ob-lilypond /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-ledger hides /usr/share/emacs/28.0.50/lisp/org/ob-ledger /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-latex hides /usr/share/emacs/28.0.50/lisp/org/ob-latex /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-js hides /usr/share/emacs/28.0.50/lisp/org/ob-js /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-java hides /usr/share/emacs/28.0.50/lisp/org/ob-java /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-io hides /usr/share/emacs/28.0.50/lisp/org/ob-io /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-hledger hides /usr/share/emacs/28.0.50/lisp/org/ob-hledger /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-haskell hides /usr/share/emacs/28.0.50/lisp/org/ob-haskell /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-groovy hides /usr/share/emacs/28.0.50/lisp/org/ob-groovy /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-gnuplot hides /usr/share/emacs/28.0.50/lisp/org/ob-gnuplot /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-fortran hides /usr/share/emacs/28.0.50/lisp/org/ob-fortran /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-forth hides /usr/share/emacs/28.0.50/lisp/org/ob-forth /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-exp hides /usr/share/emacs/28.0.50/lisp/org/ob-exp /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-eval hides /usr/share/emacs/28.0.50/lisp/org/ob-eval /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-eshell hides /usr/share/emacs/28.0.50/lisp/org/ob-eshell /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-emacs-lisp hides /usr/share/emacs/28.0.50/lisp/org/ob-emacs-lisp /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-ebnf hides /usr/share/emacs/28.0.50/lisp/org/ob-ebnf /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-dot hides /usr/share/emacs/28.0.50/lisp/org/ob-dot /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-ditaa hides /usr/share/emacs/28.0.50/lisp/org/ob-ditaa /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-css hides /usr/share/emacs/28.0.50/lisp/org/ob-css /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-core hides /usr/share/emacs/28.0.50/lisp/org/ob-core /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-coq hides /usr/share/emacs/28.0.50/lisp/org/ob-coq /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-comint hides /usr/share/emacs/28.0.50/lisp/org/ob-comint /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-clojure hides /usr/share/emacs/28.0.50/lisp/org/ob-clojure /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-calc hides /usr/share/emacs/28.0.50/lisp/org/ob-calc /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-awk hides /usr/share/emacs/28.0.50/lisp/org/ob-awk /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-asymptote hides /usr/share/emacs/28.0.50/lisp/org/ob-asymptote /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-abc hides /usr/share/emacs/28.0.50/lisp/org/ob-abc /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-R hides /usr/share/emacs/28.0.50/lisp/org/ob-R /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-J hides /usr/share/emacs/28.0.50/lisp/org/ob-J /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20200413/ob-C hides /usr/share/emacs/28.0.50/lisp/org/ob-C Features: (shadow sort bbdb-message mailalias bbdb-mua bbdb-com crm bbdb bbdb-site timezone mail-extr emacsbug message rmc puny format-spec rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils shell pcomplete comint ansi-color misc minibuffer-extras package-lint rx let-alist flimenu dash imenu finder executable noutline outline checkdoc lisp-mnt misearch multi-isearch dired-aux vc-git diff-mode misc-text dired dired-loaddefs pcase pulse xref project view jka-compr eieio-opt speedbar ezimage dframe find-func help-fns radix-tree goto-addr thingatpt pdf-loader paren elec-pair ace-link avy ring beginend dot-mode eval-region-advice gobble-whitespace icomplete-vertical icomplete minibuf-eldef mb-depth orderless block-undo modus-vivendi-theme modus-operandi-theme cus-edit cus-start cus-load wid-edit gcmh diminish cl-extra help-mode use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key easy-mmode use-package-core finder-inf edmacro kmacro tex-site info package easymenu browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 325969 129934) (symbols 48 41718 7) (strings 32 116241 15819) (string-bytes 1 3075775) (vectors 16 34929) (vector-slots 8 1212945 190082) (floats 8 103 514) (intervals 56 355 253) (buffers 992 12)) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 14 19:07:01 2020 Received: (at 40625) by debbugs.gnu.org; 14 Apr 2020 23:07:01 +0000 Received: from localhost ([127.0.0.1]:34976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOUdw-0002Fw-LF for submit@debbugs.gnu.org; Tue, 14 Apr 2020 19:07:01 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:40203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOUdt-0002Fe-Rx for 40625@debbugs.gnu.org; Tue, 14 Apr 2020 19:06:59 -0400 Received: by mail-wm1-f54.google.com with SMTP id a81so16361463wmf.5 for <40625@debbugs.gnu.org>; Tue, 14 Apr 2020 16:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bAuRRqegw84fTt4aQD5/tIpXFt3uWKHkah7ZVbtOHwM=; b=mzlytFQCbTov7qnMGhhzDWrITBOkDXAoZ2GMmmxYbdfstpXEeoRN1Hy0ok0SBZSXAU 4Zc7dzECzgylJoH1L/XMPaVJmMUi9hLi0d19lGDZSDb4zLXTKPCX55XKAxOAZNw+Ap0z YvTrHl+6f4DIWUVMSx+R2hH8n0bYuXm9D1EtZ5bIbgjtYTkkF7G4RSFG9SyKobuRp+T+ SeY9K5RgkB4Zn2vr27QFOa6SzESxOMi5TWuPu7wCmtLmjPVFCej97ZtBF1n96i5TLSVL HwQDnIikKo6UWGFYr4NIohQKtmzgZ9yydLwdqgq43XuGqkWISXhxA2v8p8cinOpgOoyN 5r3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bAuRRqegw84fTt4aQD5/tIpXFt3uWKHkah7ZVbtOHwM=; b=lLRC4G5iqqNFw1qcvrPqTryuI4HN55IcAj7CroB372vU90FE8XxM57Dn2JzpvF+3zA nzRKg/jWN+xvuqFQJ/j+IykjZlH4auSMDQPk3b0akeiLJUT+707V3h8w9LxThhTbJh8T Jmv0ftU+njmagFgoRec7jT1ntQVMwur4WDTIDXcL09ye0m9F5g7wbic9vlBsx9psHS0g uCF/f7ptZWGlnpb9rtyNPqmS3Su+KeB02QL3eAlTtFbS23iv4M6wNcQaWtAE2qdZSmqK +iX6+9GVYQkf0AwtZD4c8XEO9b49MkZIzMKQmnBlxO9+u6WtniAPsKpMhMFdZ+tmUgNo YbZQ== X-Gm-Message-State: AGi0PuZ5rWdRSpTfZHXduE8lUKr7BnHeD5X8QVoRIMwi/axI3e0KXJfB niIjNCZcSB1sNw2t/D6HBbI= X-Google-Smtp-Source: APiQypInAaqZXCfzxCkYFJNbZLwZ+GeFI8iWl9G78u1gW1GvGPQeLZjZI7QU0qHCYzda0dFWjwUkWg== X-Received: by 2002:a1c:9d84:: with SMTP id g126mr1963087wme.184.1586905611897; Tue, 14 Apr 2020 16:06:51 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a7sm4272939wrs.61.2020.04.14.16.06.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2020 16:06:50 -0700 (PDT) Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: =?UTF-8?Q?Omar_Antol=c3=adn_Camarena?= , 40625@debbugs.gnu.org References: <87lfmy6oq7.fsf@matem.unam.mx> From: Dmitry Gutov Message-ID: Date: Wed, 15 Apr 2020 02:06:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <87lfmy6oq7.fsf@matem.unam.mx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 40625 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) 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.:) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 14 20:05:16 2020 Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 00:05:16 +0000 Received: from localhost ([127.0.0.1]:34991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOVYK-0003eY-9K for submit@debbugs.gnu.org; Tue, 14 Apr 2020 20:05:16 -0400 Received: from mail-io1-f47.google.com ([209.85.166.47]:33429) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOVYI-0003eI-L8 for 40625@debbugs.gnu.org; Tue, 14 Apr 2020 20:05:15 -0400 Received: by mail-io1-f47.google.com with SMTP id o127so15275221iof.0 for <40625@debbugs.gnu.org>; Tue, 14 Apr 2020 17:05:14 -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=nwCos7YM0SbuTe3tUsZQh8tdYE2Pv0jV3rY0uJYgaPw=; b=V9hynIaFA0YV2N+IN+vNyZIcPvpbvQyfW2YtLEnhZLVJ+vxAlAirhN5dJ3Ppd6AAc8 rtuelotkD0KIYJ7qIiPW8asHLX8DsfmNcu6ocBrydVVT3mXhfN0zeFn6xtCS7VgzjadU rzYOuGZYsCGRw9MLFEUjOTcVpMtcob2vnpTARbVrMY3RjypFjY7MvUhU+IbGAiXpNfiR eZeGgoWSgsvYM2oM8EoZh0FYNcQMOU3pKLpXcs1lCaBLAb/7n8CKBSvpL8gMpa8oLmsr r7Rczq9mzXpJf+f7d3Uyawbh3ippbftKD8xBwSNUW0tIhHtD2h+e8VMUdpYB3vljD+Wu 81Eg== 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=nwCos7YM0SbuTe3tUsZQh8tdYE2Pv0jV3rY0uJYgaPw=; b=H+DsI8TTnplSowgs/g3orWPIjysk9VkouqHFP5rC1PofO89HOqJBOQBdU/VflFWIza KzozasQJ4UyQrQGCfM6jSEcgP+PcZooEUjdx7uBrSie+YS2dtRId89fUx2idPnCqr1tX QbM3AI1ygcwRbVzYT37LShzDBi8tai0TKYzpAzGvlxRi3c6h17ayiB5iKlQJBFhsFQVz ciFS7h3VmBb4gWyyXqI256g8IHtfBngCbepgAH4IMyPB3fS6moBAul0Kaaf0jveDYWLu rlJfyoKOD0L9K1I8ktk0yUVz2yJDFOxxZaB7v5hM3DLsK+YqqGiEf71jNRYC1NgbBuyX MKtA== X-Gm-Message-State: AGi0Pub9k2Auq2Fcly6ecfcAo5e/cIoFj935nC2QSzGmRE7R2Lst5IGO K1/SQSVygl2L9bOAhh7YCo8SHMc/YFoPjO0XdKg= X-Google-Smtp-Source: APiQypIHmStecX8JiKtyU3CFapkRPjnaPo8+b8c5HJu+vUaoObVaXDh8ucV/EJvgWfRreDTbrlrpi1qYdKQcnqa0duc= X-Received: by 2002:a5d:984b:: with SMTP id p11mr23796682ios.175.1586909108923; Tue, 14 Apr 2020 17:05:08 -0700 (PDT) MIME-Version: 1.0 References: <87lfmy6oq7.fsf@matem.unam.mx> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 15 Apr 2020 01:04:58 +0100 Message-ID: Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: Dmitry Gutov Content-Type: multipart/alternative; boundary="000000000000ba718b05a3491181" X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 40625 Cc: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= , 40625@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) --000000000000ba718b05a3491181 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 (al= l > 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 th= e > 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 typ= e > "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. Us= e > `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 director= y > 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 discovere= d > it has more fundamental problems with spaces than that.:) > > --000000000000ba718b05a3491181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is likely the flex completion style, not fido-mode i= tself.

I'll look into it.<= /div>

Jo=C3=A3o
On Wed, A= pr 15, 2020, 00:06 Dmitry Gutov <dgu= tov@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=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.:)

--000000000000ba718b05a3491181-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 15 11:47:02 2020 Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 15:47:02 +0000 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 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 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) MIME-Version: 1.0 References: <87lfmy6oq7.fsf@matem.unam.mx> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 15 Apr 2020 16:46:41 +0100 Message-ID: Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: Dmitry Gutov Content-Type: multipart/alternative; boundary="000000000000ae297d05a356396d" X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 40625 Cc: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= , 40625@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) --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-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 15 12:02:42 2020 Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 16:02:42 +0000 Received: from localhost ([127.0.0.1]:36962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOkUq-0004sI-Ui for submit@debbugs.gnu.org; Wed, 15 Apr 2020 12:02:41 -0400 Received: from mail-io1-f49.google.com ([209.85.166.49]:43124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOkUo-0004s5-HN for 40625@debbugs.gnu.org; Wed, 15 Apr 2020 12:02:39 -0400 Received: by mail-io1-f49.google.com with SMTP id 19so1785147ioz.10 for <40625@debbugs.gnu.org>; Wed, 15 Apr 2020 09:02:38 -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=85mrhz9CeozfD3dGoVVGiBv5oUwFln3t2RQ7lDkc5FY=; b=BNA7ICDaesp9alhERm1HGC8K5Cc9gIsuzQ7Uag1SlBqhN2Wg3PTVeB0mmB6iwKdSRJ Og/HcA18zJkne7ngwGO+BxZeQF0gf96c8a/nh0NoM6BLQGUEje4pNJ72Ilyh4Vex/Cu4 TxDPG4oNpp0DsCFQUmVYQN2p53u4Eo1M0bmMrNEB4DKkwwBmGF4FFUHJ7B2g7Awohe56 kW3ErAWeDBY0TMfBNzw4uIEd40xwIdKo31kqjxL8c7DtQB/6SBjJs466w3Tsc1svQwTI dZWdawrk/RBuSg57efwQqeXlPtM/c7jHPLxXXaz3odKuly7LkTyLMVTS6T4vLDzvn7ue f7Jg== 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=85mrhz9CeozfD3dGoVVGiBv5oUwFln3t2RQ7lDkc5FY=; b=XBgiWxe44lbBOUIYJyD+8050mcpCDWRf8D7xqnxRm5r/SurmVJkS8urYTDveblnBfM kZ8PFMoU1v/lQrIQJJ2Cq5k9EgvgReAZv12uIgvyJ/GY9CZ7FyI4/fNBfI6eWK0PTjHv YD1uVVOBfCp5lS4NRL8bF+jG/TbzRxTnDYXavivwjeRNEgTIvRauQxNANPnZssI2RqnA 5Vl5djDCTmH+vsG7M5cmQw/FZ658Gsgrv3/g+BxDAVO5uIko3YmjaQHNH9VsQ5diJ1vq 0weQNlAHx70ewQ3J35zqjVAAJYuJrXwr6bo8H/NbD5TkrGIEjK9Pl4rTVKtCogfoBDew 6LZQ== X-Gm-Message-State: AGi0PubbfkXQKLhmVcobsBYmwRVjZiNZdNT5P9yb08BjqcJs0AzCRVMC imLyHaIPxJrn3zaoWY90CTOPGE6Ac9A/F4MOYbI= X-Google-Smtp-Source: APiQypKtVW0iGRyG1y6V/HpZfImzU/BswRYWlJXU5OSJN0rz4dMgjy8tabidRIbiEUwXZbVvjKnpThez956igzduo0g= X-Received: by 2002:a5d:984b:: with SMTP id p11mr26896768ios.175.1586966552852; Wed, 15 Apr 2020 09:02:32 -0700 (PDT) MIME-Version: 1.0 References: <87lfmy6oq7.fsf@matem.unam.mx> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 15 Apr 2020 17:02:21 +0100 Message-ID: Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: Dmitry Gutov , Thierry Volpiatto , Eli Zaretskii , Stefan Monnier Content-Type: multipart/alternative; boundary="000000000000a73cac05a35671fb" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40625 Cc: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= , 40625@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000a73cac05a35671fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=A3o On Wed, Apr 15, 2020 at 4:46 PM Jo=C3=A3o T=C3=A1vora wrote: > 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 >>> my home directory starts with "one". In find-file when I type "one" I s= ee >>> 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 match= es]" >>> which is >>> > clearly wrong). >>> > >>> > If after entering "one" I press space, I get "one [No matches]", tha= t >>> 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 t= ype >>> "a " (that's a followed by space), I see "~/a [No matches]". Even typin= g "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 o= ffer >>> 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 nothi= ng >>> happens (space is bound to minibuffer-complete-word), no space is enter= ed, >>> the candidates don't change. Pressing space again pops up the completio= ns >>> 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 r= un). >>> It uses `backward-kill-sexp', which means it won't fully go up a direct= ory >>> 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=C3=A3o T=C3=A1vora > --=20 Jo=C3=A3o T=C3=A1vora --000000000000a73cac05a35671fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, here's the origin of the = completion-flex-nospace var.=C2=A0
More people were involved= , seems I didn't just pull this out
of thin air :-).
=


The purpose of tha= t variable is to be set to t when the user wants
to add othe= r completion styles after `flex' in the completion-styles
var= iable.=C2=A0 It doesn't make much sense for fido-mode, because
fido-mode only uses one style by definition.=C2=A0 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:


I seem to have proposed to set it to t so that users could more
easily compose flex with their special helm styles.=C2=A0 But then <= br>
Thierry said those styles are Helm-UI specific anyway and
the discussion to make them available to more Emacs users
= never unfolded.=C2=A0 So, I think the rationale for having
c= ompletion-flex-nospace default to t is mostly gone.=C2=A0 I mean,
users that do come up with some fancy-shmancy style
can set them= to t themselves, right?

So I propose we defau= lt it to nil. What do you guys think?

Also, be= cause flex is a new thing in Emacs 27 anyway,
I propose we do= it in the emacs-27 branch.=C2=A0 Eli?

Jo=C3=A3o



=
On Wed, Apr 15, 2020 at 4:46 PM Jo=C3= =A3o T=C3=A1vora <joaotavora@gma= il.com> wrote:
Found these two commits:

commit 6d4d00c63417e3479e978a373f252b9f2709ce39
Author: Jo=C3=A3o T= =C3=A1vora <jo= aotavora@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-flex-nospace nil
- =C2=A0"Make flex style f= ail 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 5a62c4b49ca1ac45d576f55d266750b= 7d1d6668a
Author: Thierry Volpiatto <thierry.volpiatto@gmail.com>
Dat= e: =C2=A0 Thu Nov 21 20:41:19 2019 +0100

=C2=A0 =C2=A0 Add new varia= ble to prevent flex completion style
=C2=A0 =C2=A0
=C2=A0 =C2=A0 mat= ching spaces.=C2=A0 This allows flex style working 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-nospace): New user var.
=C2= =A0 =C2=A0 (completion-flex-try-completion): Use it.
=C2=A0 =C2=A0 (comp= letion-flex-all-completions): Same.

diff --git a/lisp/minibuffer.el = b/lisp/minibuffer.el
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.e= l
@@ -3497,0 +3497,4 @@
+(defcustom completion-flex-nospace nil
+ = =C2=A0"Make flex style fail when a space is found in pattern."+ =C2=A0:version "27.1"
+ =C2=A0:type 'boolean)

I honestly _don't_ remember discussing this (says a lot= for for
the state of my brain lately).

<= /div>
But it seems reasonable for users that wish to use spaces to
=
set this to nil, so hopefully the emergency is resolved.=C2=A0 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 "reject= ion" of space
should be handled differently: I agree this is= confusing.

Jo=C3=A3o

On Wed, Apr 15, 202= 0 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.

I'll look into it.

=
Jo=C3=A3o

On Wed, Apr 15, 2020, 00:06 Dmitry Gutov &= lt;dgutov@yandex.ru> wrote:
Th= anks 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


--
Jo=C3=A3o T=C3=A1vora
--000000000000a73cac05a35671fb-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 15 12:06:22 2020 Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 16:06:22 +0000 Received: from localhost ([127.0.0.1]:36966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOkYQ-0004y5-7S for submit@debbugs.gnu.org; Wed, 15 Apr 2020 12:06:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOkYO-0004xp-LS for 40625@debbugs.gnu.org; Wed, 15 Apr 2020 12:06:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jOkYI-0001uf-M1; Wed, 15 Apr 2020 12:06:14 -0400 Received: from [176.228.60.248] (port=3424 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jOkY9-0001Uc-1Y; Wed, 15 Apr 2020 12:06:13 -0400 Date: Wed, 15 Apr 2020 19:05:46 +0300 Message-Id: <83pnc8g2ed.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Wed, 15 Apr 2020 17:02:21 +0100) Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space References: <87lfmy6oq7.fsf@matem.unam.mx> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 40625 Cc: omar@matem.unam.mx, thierry.volpiatto@gmail.com, monnier@iro.umontreal.ca, 40625@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) > From: João Távora > Date: Wed, 15 Apr 2020 17:02:21 +0100 > Cc: Omar Antolín Camarena , > 40625@debbugs.gnu.org > > 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? If the consensus is to set it to nil, then it's okay for Emacs 27. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 15 13:18:01 2020 Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 17:18:01 +0000 Received: from localhost ([127.0.0.1]:37024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOlfl-0000S6-4w for submit@debbugs.gnu.org; Wed, 15 Apr 2020 13:18:01 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:38629) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOlfj-0000Rr-8N for 40625@debbugs.gnu.org; Wed, 15 Apr 2020 13:18:00 -0400 Received: by mail-wr1-f52.google.com with SMTP id k11so799614wrp.5 for <40625@debbugs.gnu.org>; Wed, 15 Apr 2020 10:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=98RnzcWDZuTEJ3bUeoCMTE+2HeQ1/uwiKJC5AOG9g8Q=; b=Y71JW7JPPOMjcT5GE3AG83FhWCAXP/GhCVtGQU79yCr9eLtgzqz8GSN+CV407DXOmA gYN1GWi5LFH4fRpNBUlTWxcFtbc5UwlHQIyT8ROxS/e0oXzKvhMDYOFpOtx+K/kIr8r+ s8946WnfjV1MGj9/kmNYlQF81ibZimsekeihF7PtJpTm26+Qimgvn9MMk3RAfBsHxrT1 UpIVrrNm3EtbegatFIsXUZ4ro9GyOc6+kDETKzSEf0WOHoDX0lBdRJ5z54E6z54zj5Es ErVFFTzNp8MUKZwpNkQfPek5ZHURb6seh2wpy4cLbc5HLVjeVuaitBXpUEEuontvfNmm /yPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=98RnzcWDZuTEJ3bUeoCMTE+2HeQ1/uwiKJC5AOG9g8Q=; b=e5nJTzkYse1MSbODBlyDcvyOGOYph5tHClIDMev+UcH+4cv9TGS4lE+ozPTJ6niYR2 c2IJrNPeSA3G9nnVj/u5T1QEvaPngUfBMMjlRIAzFZdRWVuoNf/NW+IUHQ1JOIabTAG1 tA2Ewx4Gj/q/O1m52JIvN+A4nz0jFqL2fP97wd+lI7+7qmrR3XWYJ1J4ljzXUTTmbauN v3Ji3wzN9WsG1GBqWXw1uS+KR7VfOOB8boDmQ6REcmjAveXe2ihTUIVWZrfflpbOF/sC ZhLJBHAp97auTlmLa3bXseOkyl03u+ZD4ZOzlrCmsMmb7W17V0bLcdmFrcdTtJM5SjNU qGEw== X-Gm-Message-State: AGi0PubVapZ9n6wRtQxXF/P/qi+dAL8v8GHsCfJ8KoqWUJ0AMvH/Z1bY hIyKKWs8vwuVZeEHqs8Yi7+BIDTd2fc= X-Google-Smtp-Source: APiQypJeSVipybGysqs5vB1VN7UuRwEDX04ovXjTZD6oxFMGDbdtBUSl5dxlgFc+JOmZnIuajHpg8A== X-Received: by 2002:adf:df01:: with SMTP id y1mr29911026wrl.401.1586971073084; Wed, 15 Apr 2020 10:17:53 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id i17sm241470wml.23.2020.04.15.10.17.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2020 10:17:52 -0700 (PDT) Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Thierry Volpiatto , Eli Zaretskii , Stefan Monnier References: <87lfmy6oq7.fsf@matem.unam.mx> From: Dmitry Gutov Message-ID: <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> Date: Wed, 15 Apr 2020 20:17:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 40625 Cc: =?UTF-8?Q?Omar_Antol=c3=adn_Camarena?= , 40625@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) On 15.04.2020 19:02, João Távora wrote: > So I propose we default it to nil. What do you guys think? Yes, please. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 15 13:26:42 2020 Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 17:26:42 +0000 Received: from localhost ([127.0.0.1]:37042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOlo9-0000h4-SO for submit@debbugs.gnu.org; Wed, 15 Apr 2020 13:26:42 -0400 Received: from mail-qk1-f177.google.com ([209.85.222.177]:35128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOlo8-0000gs-9y for 40625@debbugs.gnu.org; Wed, 15 Apr 2020 13:26:40 -0400 Received: by mail-qk1-f177.google.com with SMTP id c63so18173539qke.2 for <40625@debbugs.gnu.org>; Wed, 15 Apr 2020 10:26:40 -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=xAgQJuu+rdxXqeJAcIRCEj7R7wDcEyZy+l0HV9b9k54=; b=YVrWWDW9JGQxUCqg8Iv7wzu4qsA3WSGrA4EBlIZL7WwKoa4Hn6jaiNhpnVLPv4nBIo GDfcDrytmoHO81oH9Dnl1BsRhv1teUg9slsvuPrLKSEmEBFYWugp+9vbDtjUiqBwFZE8 ErAS3jdOwjds4rMPCb4XT98620yPG77BWv7nJRfn7H/AoSEyoaFDcX7svvCpUvRZJi+h sZ9/yRpv18xr9vXSqjDi1kkoG/9bEjV3FqPuafJAtPlGG1vzG7caNm0V5HmmNCTdnC2n iOSCi3H2lGd40GxJv431XVj0FYwIa74lAp2tFv6CYDW0AbrqZEFuNBNU9btDP6Ji6E30 CXRQ== 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=xAgQJuu+rdxXqeJAcIRCEj7R7wDcEyZy+l0HV9b9k54=; b=M8etJh6/upKZZNTPkcIW+xQtn88w0ogbU+inkeWb5irFjI+aH2eZidDeMEy+VGHqr4 equnrKYz53UlGCeAI0g5t3WGRlfpCdLApSTz9Z117iOZ65z41GS/+PvhgIPrR5cVTEKV f+v9U9ap9d5GYTXly1/oD3/gwp8VYSnG2r/6PDiVTzMfRp/kwhTi4/HuQ1l1NK64LkVm ANOupAs8C77BVyA2EkrwZqE0cKecQ1fnAGGj07QPT7+yRGRZ1KQHIK1tBCs3ntsfBC7A IubDJiuJwsjH56uYKJrRfzPUzI/wx0tiX0aoZ/0xRlnkhWcXh4JPkGeXC222Dq7yvWNg zClQ== X-Gm-Message-State: AGi0PuaiiyfoyuTj83y6ko0wduXMzM8xDiFmklgZe8r4xYv/c9nuuOTO eKjrMdleZLfVBUFvXVY2Mgq+cM6o+IYge6UV1Xg= X-Google-Smtp-Source: APiQypJYttZwvfDRFtYIonOTzC6s42XsFNfcp1Tn67UvNbe5B3a4P3coeWKb3lPVue+X76E9I7G70xjiIsP/3+x2frk= X-Received: by 2002:a05:620a:812:: with SMTP id s18mr17052024qks.64.1586971594721; Wed, 15 Apr 2020 10:26:34 -0700 (PDT) MIME-Version: 1.0 References: <87lfmy6oq7.fsf@matem.unam.mx> <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> In-Reply-To: <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> From: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= Date: Wed, 15 Apr 2020 12:26:21 -0500 Message-ID: Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: Dmitry Gutov Content-Type: multipart/alternative; boundary="0000000000002c1f9105a3579e11" X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 40625 Cc: 40625@debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Thierry Volpiatto , =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= , Eli Zaretskii , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) --0000000000002c1f9105a3579e11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that nil would be a less confusing default for completion-flex-no-space, but I am still confused about something: why is that variable relevant in the first place? Does fido-mode use the flex completion style unconditionally, ignoring the user's setting of completion-styles and completion-category-overrides? On Wed, Apr 15, 2020 at 12:17 PM Dmitry Gutov wrote: > On 15.04.2020 19:02, Jo=C3=A3o T=C3=A1vora wrote: > > So I propose we default it to nil. What do you guys think? > > Yes, please. > --=20 Omar Antol=C3=ADn Camarena --0000000000002c1f9105a3579e11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that nil would b= e a less confusing default for completion-flex-no-space, but I am still con= fused about something: why is that variable relevant in the first place? Do= es fido-mode use the flex completion style unconditionally, ignoring the us= er's setting of completion-styles and completion-category-overrides?

On Wed, Apr 15, 2020 at 12:17 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
On 15.04.2020 19:02, Jo=C3=A3o T=C3=A1v= ora wrote:
> So I propose we default it to nil. What do you guys think?

Yes, please.


--
Omar Antol=C3=ADn Camarena
--0000000000002c1f9105a3579e11-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 15 13:41:56 2020 Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 17:41:56 +0000 Received: from localhost ([127.0.0.1]:37073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOm2t-000176-WC for submit@debbugs.gnu.org; Wed, 15 Apr 2020 13:41:56 -0400 Received: from mail-io1-f43.google.com ([209.85.166.43]:46641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOm2s-00016t-AX for 40625@debbugs.gnu.org; Wed, 15 Apr 2020 13:41:54 -0400 Received: by mail-io1-f43.google.com with SMTP id i3so17983695ioo.13 for <40625@debbugs.gnu.org>; Wed, 15 Apr 2020 10:41:54 -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=HDkVwObETGQOJTQB4slXOqRxzHTLkSzyRoDCRZs/fEU=; b=VdDS9VQydYP2CVILC3x2U/MjhNhbbiDxgdGwNEZMGi5Hxh1tyJwKExi15qDPilL6XM /Ay4qSdlklWCbzJJO/WHIlbSjSi0uT+YePdsmun4Iv5HqBZ26BiqpUACZYt5tO9ngcrc A2sWZ7IJmGUPBDSCGGvDWxZWUQVl8jhvx5lBIEtS6+ntFj0R5jR5fj0Hwk18f5mnzER0 giwZvY5+YOoYwdz1hc+2AsccAjWAE4Mmg99Nib40CpKfl04j9cFuMtEsobO4uXkla5/7 WkEBafEVckdjK/Q27IJhc69dDE6g68xeVrmu3N4NgaFjA2R6hy3f+ol66Ir/839iHsom 7eGw== 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=HDkVwObETGQOJTQB4slXOqRxzHTLkSzyRoDCRZs/fEU=; b=LPW3+TnxlltFOpvP+HH/k3Du28CDsILPYBlz+fZhKaZjKzCp5H37AVNFYHovBqXfp/ 1tVoqcH/by4jq9rAWWGvvN9e8RKYiFTl+lMFCifK2yiRwrX5D0bIusm5iAgBsgOYj/WK nqli2mzZTesdj5hEapF6rqatq8ILPmKonXfqpHd1U0QaVy/MU2GIC1iWZCXrFewU2oyT hdbabBONm5S4/W0KFGDcXpWASdXH968NtmnWRq6DLn3TPVRoi0ZHo+RmruHMcBCR4ecp uiDwKtuMmy9uDCIQFFZ+HDudXBJKo2WNGUsySAGMKEyXKc46evT+qxMXqy+nmwhWRMpp VzYQ== X-Gm-Message-State: AGi0Puao62mEj1aBXCHJFhuKAfxlzmyqg07AyJGgJjFgCG6+5TdXarYq wrwpNB7pIyBcheXyA842GQ5a872NQqkwUl1+RdY= X-Google-Smtp-Source: APiQypLddcFyxQAA7QTUsMG5WXsTn4FgvbUZERDk2ao7WSL8N3BoA32qN0KIPYxoOwljZkuHDHuqhuzdQuXhzHiaQNQ= X-Received: by 2002:a02:58c3:: with SMTP id f186mr9580834jab.120.1586972508677; Wed, 15 Apr 2020 10:41:48 -0700 (PDT) MIME-Version: 1.0 References: <87lfmy6oq7.fsf@matem.unam.mx> <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 15 Apr 2020 18:41:35 +0100 Message-ID: Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= Content-Type: multipart/alternative; boundary="000000000000a5e8db05a357d458" X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 40625 Cc: 40625@debbugs.gnu.org, Dmitry Gutov , Stefan Monnier , Thierry Volpiatto , =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) --000000000000a5e8db05a357d458 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2020 at 6:26 PM Omar Antol=C3=ADn Camarena < omar.antolin@gmail.com> wrote: > Does fido-mode use the flex completion style unconditionally, ignoring the user's setting of completion-styles and completion-category-overrides? Yes. That is by design. If you want to tweak, you should be able to use minibuffer-setup-hook for that. I think Dmitry wants to add some new variables to allow fido-mode specific settings, but don't think that's a good idea. That's not to say this shouldn't be easier, but I think adding variables to fido-mode is not the way to go. Could end up with fido-specific versions of every such variable. I prefer to review the other variables, their values and semantics so we come up with a holistic solution. For Emacs 28. Jo=C3=A3o --000000000000a5e8db05a357d458 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 15, 2020 at 6:26 PM Omar Antol=C3=ADn Camarena= <omar.antol= in@gmail.com> wrote:

> Does fido-mode use the flex co= mpletion style unconditionally, ignoring the user's setting of completi= on-styles and completion-category-overrides?

Yes.= =C2=A0 That is by design.

If you want to tweak= , you should be able to use
minibuffer-setup-hook for that. = I think Dmitry wants
to add some new variables to allow fido-mod= e
specific settings, but don't think that's a good idea.=

That's not to say this shouldn't be e= asier, but I think adding
variables to fido-mode is not the way t= o go. Could end
up with fido-specific versions of every such vari= able. I prefer
to review the other variables, their values a= nd semantics
so we come up with a holistic solution.=C2=A0 F= or Emacs 28.

Jo=C3=A3o
--000000000000a5e8db05a357d458-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 15 13:44:46 2020 Received: (at 40625-done) by debbugs.gnu.org; 15 Apr 2020 17:44:46 +0000 Received: from localhost ([127.0.0.1]:37077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOm5e-0001Bc-EJ for submit@debbugs.gnu.org; Wed, 15 Apr 2020 13:44:46 -0400 Received: from mail-il1-f170.google.com ([209.85.166.170]:46909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOm5d-0001BQ-56 for 40625-done@debbugs.gnu.org; Wed, 15 Apr 2020 13:44:45 -0400 Received: by mail-il1-f170.google.com with SMTP id i75so4119319ild.13 for <40625-done@debbugs.gnu.org>; Wed, 15 Apr 2020 10:44:45 -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=wMF4MwsW79IS8mTFHuH+ogIg8Ss/iqhwwgo+g4nz8nE=; b=i/HbNzFIGtKnl7YnFbYtgT4k5ffjBJv9sZ6Ueekcc2kAcSHN3W8NMAOFuX0HhS4g3P x2fxHy0NUY6nzpeuacfR1wvFc68KV9jXxe3eOKUCV9Q2/RJXivd0b46dCsuPB1ppIUfP JHx6WS1HAqF9LyFYxX3eZFszW4gY0nEuj+du2bHHHYAb6QBl+nodueZ7gAa1PqLTWtkv 5sE+r/1KQNe/2wp3qTxzLC80OBuJF6cponpluGRgDv4iuxVdugWwO29UtK/J/ouKB7J8 Qy3yY786ljqxrBd2g0/qA2+hOT5tH4dlBOmEl3aWysppCb9gIfq7ZGK0LAcHcDhCtxNv IqdQ== 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=wMF4MwsW79IS8mTFHuH+ogIg8Ss/iqhwwgo+g4nz8nE=; b=NGumBep7obeZwsIYMq//BPO1Em0jONATSwd6br1vCwROm6asPdk6nxYPy0tF4Ke9vv z7tuGNvLLSnPammY/gCrfIwpnAFt+T5l8ywLsLcEaxIJP5fv95QZWv8ZKnmjYg28y4ZW vIAABvQ9f8u4O1vB6aZc7IHbHiIHWIEJlDpO63st/9ktfX9OEe1v0H6ZNE+BKj1ovgC8 VALNmOlaBE1krKc24uaCkz8PY3YdC7uVj8XVxsZjCMZWvL7sYR43Askq5MTp80INF5Kb DKNsYQrJIRD7wCv8o/k4SuBuYhhZUYeVl0Vdqo/p/ir6L+1HrD8kaC0V2KFl0lg/BVG0 leRA== X-Gm-Message-State: AGi0PubgNFis1RIPtF5XJjoT+nSHi8GB7xTWDiWw5PGerPMdAij0teqV amMYUh1XeLuz5GCGX4zym4OzC81nF4syILmk/Oc= X-Google-Smtp-Source: APiQypKlJ8xcSbpaZIG/QWDPXG7CZZhO4hr+s9Has2JX+bF5uuiYMTOM7U1hc9fffb1oGV9JElvBoclE0etjzgCasvc= X-Received: by 2002:a92:d0d0:: with SMTP id y16mr1943894ila.125.1586972679663; Wed, 15 Apr 2020 10:44:39 -0700 (PDT) MIME-Version: 1.0 References: <87lfmy6oq7.fsf@matem.unam.mx> <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> In-Reply-To: <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 15 Apr 2020 18:44:26 +0100 Message-ID: Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: Dmitry Gutov Content-Type: multipart/alternative; boundary="000000000000d6f32505a357de22" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40625-done Cc: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= , Eli Zaretskii , Stefan Monnier , 40625-done@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d6f32505a357de22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2020 at 6:17 PM Dmitry Gutov wrote: > > On 15.04.2020 19:02, Jo=C3=A3o T=C3=A1vora wrote: > > So I propose we default it to nil. What do you guys think? > > Yes, please. Done. Closing this. --000000000000d6f32505a357de22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 15, 2020 at 6:17 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>= ; On 15.04.2020 19:02, Jo=C3=A3o T=C3=A1vora wrote:
> > So I propo= se we default it to nil. What do you guys think?
>
> Yes, = please.

Done. Closing this.
--000000000000d6f32505a357de22-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 15 15:38:25 2020 Received: (at 40625) by debbugs.gnu.org; 15 Apr 2020 19:38:25 +0000 Received: from localhost ([127.0.0.1]:37160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOnrd-0004J6-FI for submit@debbugs.gnu.org; Wed, 15 Apr 2020 15:38:25 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:38198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOnrb-0004Is-17 for 40625@debbugs.gnu.org; Wed, 15 Apr 2020 15:38:23 -0400 Received: by mail-wm1-f43.google.com with SMTP id g12so1177335wmh.3 for <40625@debbugs.gnu.org>; Wed, 15 Apr 2020 12:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RCC+35pX1AYc8ky2+HnD08SibOLRqc7J3qpbGemJLBM=; b=cNhBjVQSF+0BLI31XnnoGjNbe0yG19ZD8sa/YE0WE2n4+sWuF7mEVeqY8vf3MxZHDc Q/MUqUdDJlOEmrKLcrnArhRjWtmiZZqtFvEc4r3bxANymwrWxL3JN+BgcGvFDuRBMcmc 5k3Ftc7b75XU0qhp+rK2XWeM7hJA1OStrSLRVfNAdJJ6+tOgvMVv15xLi7sA6MWfUdls GCjRO6ad9QN82zSm2fERIhscLs9rnf2gvrvoNOEUuJf+9ciUEHSZkxMZLPZ2Ldtqq8FH KDxb3Zt4aQhkHBMe/dwBAy3N7Jcax2Q5T1P0CvVxTfjLsiJh7+JIfJgYtaOfGogNZkru 2AyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RCC+35pX1AYc8ky2+HnD08SibOLRqc7J3qpbGemJLBM=; b=cM7P+htIGU3J/0c8S06oJI/Mc67hHDzuXA/ge/P6o7j631zLV4pfhPMjTmbUJDgLyG ueQzQdcftZ21sOvWrTy2zwayh+plUUQ/n/yHxnz8X8wGCmHVCHYraTWepruoYVx6LgwO 1TvzTiPWIqMzV9EUQRadC9PuK3/E6o0J5fokJ5AnOwnfz6iv2AFMoTSOoW/jKGbtnWnm K50I6lyJgfUiKaX5Taj0ICKFLKHRL/tbcTfUr/lcHSc/XJa7qQhAw69retxc42NFnvJ8 XE3O3affvI6ziyJb8ddpBtuMb0x+roGPdD/2o1SQ9lydAdKeCaMPF8aS/YtXftRY+r63 zxXQ== X-Gm-Message-State: AGi0PuY2CuNcAwhM2+FBOO5fSZrn0L01FMwDEghXGXlzHHDrXJGDliC3 Ec3Y7bnibArPdUS/jTbs3DY= X-Google-Smtp-Source: APiQypLC0DU8P2wtlzuBQ1n+5EdesGmJzC3IXhZRfOLhaBLDgIohN7BJ1WNK5Cdlj5VpyQF9aSPP3w== X-Received: by 2002:a1c:e288:: with SMTP id z130mr168833wmg.0.1586979495869; Wed, 15 Apr 2020 12:38:15 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id g6sm5315239wrw.34.2020.04.15.12.38.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2020 12:38:14 -0700 (PDT) Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: 40625@debbugs.gnu.org, joaotavora@gmail.com, omar@matem.unam.mx References: <87lfmy6oq7.fsf@matem.unam.mx> <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> From: Dmitry Gutov Message-ID: <4a7a228c-ddcd-0f39-d7f6-5f22aef44603@yandex.ru> Date: Wed, 15 Apr 2020 22:38:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 40625 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) On 15.04.2020 20:44, João Távora wrote: > Done. Closing this. There was also a complaint about icomplete-fido-backward-updir's misbehavior when a directory contains a space at the end of the original report. I think the proposed fix is fine. Although we could also consider whether we can fix it in a way that also supports directory names with '/' in them. Completion fields and boundaries come to mind. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 16 04:39:29 2020 Received: (at 40625) by debbugs.gnu.org; 16 Apr 2020 08:39:29 +0000 Received: from localhost ([127.0.0.1]:37505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jP03V-00030M-EK for submit@debbugs.gnu.org; Thu, 16 Apr 2020 04:39:29 -0400 Received: from mail-il1-f172.google.com ([209.85.166.172]:45830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jP03T-000309-Bj for 40625@debbugs.gnu.org; Thu, 16 Apr 2020 04:39:27 -0400 Received: by mail-il1-f172.google.com with SMTP id i2so6093515ils.12 for <40625@debbugs.gnu.org>; Thu, 16 Apr 2020 01:39:27 -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=JjNEIBpmKkCafLayc8FlLJsJ0cRD903isWEWkDW8754=; b=vbfPYoC8jLLRUwnkZlXCt63fye2z9w54Q288W7o62yqhDCEMeK5UiLZjp8NtpdVYmu YepazA9Tae3DhvV2C6g4TcSmOYjPtLzAmX3Z0f8Ib7yQ5pkBQg7A10FtNHsVSmM/g3z9 4HHDeApwxo/FcUEOcc1uk7JBOstPJFSAUO9q/0JiJe/5JH13d/ZtP0UINZQDUgim3vRQ xW8+OnrBukiQG7+ILhcSskqURlFrI0lkRbU9F3NYQNglODm9jDKFAc9BzPb984J/9NRk 2RvFFzKy3nZNJcpdsChvIhE3N+qDmcLaffl4c7J5llwG7jtDpDP2c6S/5bBdnSJOg0Y3 VX2g== 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=JjNEIBpmKkCafLayc8FlLJsJ0cRD903isWEWkDW8754=; b=cFAgOb4hD1RV/1qiYir2F1ltfrDVxfecr0sRSnLqBNMYGZB/LMUQ6RNivxs0G9mZhM ZR/T0reFRkTtIJbWnaaOEf48Rr47HL38mcKfKsU6DFGBY4xLFVTN+t0GMbdoNYdR+KGs 1YNPn9pdmkyVHnrARbH2BRqfWLHiBTdn6OKEKCce5PyHrqvx6YOD2y6twEYyUUOlYK15 ia1iWEmqubuwSO+f0OM4LR/IDzG2KJaafHDh5bP7/pREUkpT0Yj0KmxBW7NisRJvvIA+ G6nwWf9KUZtALOkZdwrInfTvfnuWZs7SmB2bMsI7QHkb4uLZ9mJ0v4LEe6hjhAqURmX5 6LGg== X-Gm-Message-State: AGi0PuaLVbAlLYJojNW60lDVK68WAMttkAB2o7OGCIq1oqrAsPfWjSk1 iVe9wqC3A//QGm+40CNRtUn1oN5x5lvg9CijElI= X-Google-Smtp-Source: APiQypLIdQznu7H6H3136UZg78uQJ1oCI7NDYxSiBCMEwiZ4bBN0dEx3UYu7LDCa+52ATivCboADoU5TyPngNWlRE8M= X-Received: by 2002:a05:6e02:c25:: with SMTP id q5mr8678734ilg.97.1587026361749; Thu, 16 Apr 2020 01:39:21 -0700 (PDT) MIME-Version: 1.0 References: <87lfmy6oq7.fsf@matem.unam.mx> <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> <4a7a228c-ddcd-0f39-d7f6-5f22aef44603@yandex.ru> In-Reply-To: <4a7a228c-ddcd-0f39-d7f6-5f22aef44603@yandex.ru> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 16 Apr 2020 09:39:10 +0100 Message-ID: Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: Dmitry Gutov Content-Type: multipart/alternative; boundary="0000000000008a95e805a3645e30" X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 40625 Cc: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= , 40625@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) --0000000000008a95e805a3645e30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2020 at 8:38 PM Dmitry Gutov wrote: > > On 15.04.2020 20:44, Jo=C3=A3o T=C3=A1vora wrote: > > Done. Closing this. > > There was also a complaint about icomplete-fido-backward-updir's > misbehavior when a directory contains a space at the end of the original > report. > > I think the proposed fix is fine. Although we could also consider > whether we can fix it in a way that also supports directory names with > '/' in them. Completion fields and boundaries come to mind. I went with the simpler fix. Annnd just remembered I forgot to give Omar credit. Sorry Omar, and many thanks, Jo=C3=A3o --0000000000008a95e805a3645e30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 15, 2020 at 8:38 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>= ; On 15.04.2020 20:44, Jo=C3=A3o T=C3=A1vora wrote:
> > Done. Clos= ing this.
>
> There was also a complaint about icomplete-fido-b= ackward-updir's
> misbehavior when a directory contains a space a= t the end of the original
> report.
>
> I think the propo= sed fix is fine. Although we could also consider
> whether we can fix= it in a way that also supports directory names with
> '/' in= them. Completion fields and boundaries come to mind.

I went with the simpler fix.=C2=A0 Annnd just remembered I forgot to
=
give Omar credit.=C2=A0

Sorry Omar= , and many thanks,
Jo=C3=A3o
--0000000000008a95e805a3645e30-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 16 12:57:02 2020 Received: (at 40625) by debbugs.gnu.org; 16 Apr 2020 16:57:02 +0000 Received: from localhost ([127.0.0.1]:39275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jP7p0-0005B9-BE for submit@debbugs.gnu.org; Thu, 16 Apr 2020 12:57:02 -0400 Received: from mail-qv1-f53.google.com ([209.85.219.53]:40239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jP7oz-0005Ag-1G for 40625@debbugs.gnu.org; Thu, 16 Apr 2020 12:57:01 -0400 Received: by mail-qv1-f53.google.com with SMTP id fb4so2357872qvb.7 for <40625@debbugs.gnu.org>; Thu, 16 Apr 2020 09:57:00 -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=7sBbIpGnPjdrWmRLworhFPQ0qrDWdZGzINfHnH7trCY=; b=KTNVKOXvJWTrSRBofy7JmSR/dZiqTkbjK4PYZIhbSwHxrCsXaPtRwwSkh75TsIvNJD Ar5/AsvF6JC7jrn5p9oAZ3hFMVui+0kYWdoiAkJZodO3pNy62HiX8bgcBVBveMkbydqG SKpCyWu+32Yu5llnGUVZ2Z4QeIF/hM06P+1V2JH7nPKiq+ZNotxfE/li2JvEahNj507G DkYDxUJzkS4lBOpq+LA4TX4r2AusxmozUvKuoR55S9mW15TTHgBEk+JDpd64omgJHnRM Z+zXaV5yx4b+pyaj5V/J/l4N+R2WuoLcyOvdWsoddp3fh1c1/yrJI82K5p3lwqsjF8DS ZJXg== 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=7sBbIpGnPjdrWmRLworhFPQ0qrDWdZGzINfHnH7trCY=; b=uSCGcLEyIGzXuYPOjkEyR2Fvli64vYXChcALXOWhKOROrVgcHGOVzPrqKxhS9glcKE GgzThH+9DZRIHEUM1sf5A87twX2acqSPckwcIof9CU8lUcm59scXJmS/EienE+SLhRbR puwJBsZWRNxI7nZUxrsDQ0Ixa7JN8uDaC03UWjNoWi6VJBh93h50DUCNNkTg4QI2xfrA gC377zmZnbuPJsJ/bWr3CRfUsBdIHIOUHcF2cqaCt+e24VkQLc7ikWAUgJ4pYbkq9lv/ nP8AQdgb29LQ2SOhce8TkuMJKdGOHpbl8NkfKomq3zSpSi3+AYPDP7DZYVJzfoRwWWFD nyWw== X-Gm-Message-State: AGi0PuY4Zxe6qbNmO4oxNG6J4ApnV2onkXMQfo6RTA2GCabmCWRPcemo h6YMEDiUqXiHF5umtrZDAt161tynYz/nOiY9JEo= X-Google-Smtp-Source: APiQypJQ1QSJ29/BT2mTL2QKRTdB0j4ZPDjBdzj5qcdoXXDwvLv//jp1V1ydgi69tGEU0JPfDiepciTnnYhLKGic5HA= X-Received: by 2002:a0c:9aea:: with SMTP id k42mr11106663qvf.91.1587056215318; Thu, 16 Apr 2020 09:56:55 -0700 (PDT) MIME-Version: 1.0 References: <87lfmy6oq7.fsf@matem.unam.mx> <15a3769d-49a6-2b6a-ca6a-5fa6d154e3a8@yandex.ru> <4a7a228c-ddcd-0f39-d7f6-5f22aef44603@yandex.ru> In-Reply-To: From: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= Date: Thu, 16 Apr 2020 11:56:43 -0500 Message-ID: Subject: Re: bug#40625: 28.0.50; fido-mode cannot match candidates containing a space To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Content-Type: multipart/alternative; boundary="000000000000f3e54005a36b514b" X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 40625 Cc: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= , 40625@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) --000000000000f3e54005a36b514b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Sorry Omar, and many thanks, > Jo=C3=A3o > No problem, and thanks for fixing this so quickly! > --=20 Omar Antol=C3=ADn Camarena --000000000000f3e54005a36b514b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry Omar, and many thanks,
Jo=C3=A3o

No problem, and = thanks for fixing this so=C2=A0quickly!
=

--
Omar Antol=C3=ADn Camarena
--000000000000f3e54005a36b514b-- From unknown Sat Jul 26 23:56:33 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 15 May 2020 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator