unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
@ 2020-04-14 16:01 Omar Antolín Camarena
  2020-04-14 23:06 ` Dmitry Gutov
  0 siblings, 1 reply; 13+ messages in thread
From: Omar Antolín Camarena @ 2020-04-14 16:01 UTC (permalink / raw)
  To: 40625


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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-14 16:01 bug#40625: 28.0.50; fido-mode cannot match candidates containing a space Omar Antolín Camarena
@ 2020-04-14 23:06 ` Dmitry Gutov
  2020-04-15  0:04   ` João Távora
  0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Gutov @ 2020-04-14 23:06 UTC (permalink / raw)
  To: Omar Antolín Camarena, 40625; +Cc: João Távora

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.:)






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-14 23:06 ` Dmitry Gutov
@ 2020-04-15  0:04   ` João Távora
  2020-04-15 15:46     ` João Távora
  0 siblings, 1 reply; 13+ messages in thread
From: João Távora @ 2020-04-15  0:04 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Omar Antolín Camarena, 40625

[-- Attachment #1: Type: text/plain, Size: 3512 bytes --]

This is likely the flex completion style, not fido-mode itself.

I'll look into it.

João

On Wed, Apr 15, 2020, 00:06 Dmitry Gutov <dgutov@yandex.ru> wrote:

> Thanks for the report.
>
> I can reproduce all three.
>
> FWIW, the "bare" icomplete-mode works fine in these cases.
>
> On 14.04.2020 19:01, Omar Antolín Camarena wrote:
> > Here are 3 scenarios I tested with fido-mode starting from emacs -Q (all
> of these work perfectly with icomplete):
> >
> > 1. Files with spaces.
> >
> > Run emacs -Q and use `M-x fido-mode' to activate fido-mode.
> > Create a file with a space in the name. Use find-file to try to open it.
> As soon as you have a space in the minibuffer, it says "[No matches]".
> >
> > For example, I created a file called "one two", and no other file in my
> home directory starts with "one". In find-file when I type "one" I see the
> expected result: "~/one[ two] [Matched]".
> >
> > If I press TAB to complete I get "one two [No matches]" (from there I
> can press RET to open the file, this bug report is about the "[No matches]"
> which is
> > clearly wrong).
> >
> > If after entering "one" I press space, I get "one  [No matches]", that
> it, I no longer get offered the "one two" completion.
> >
> > 2. Directories with spaces.
> >
> > In emacs -Q use `M-x fido-mode' to activate fido-mode.
> > Create a directory with a space in the name. I created a directory
> called "a b" and put a file called "c" inside. If I run find-file and type
> "a " (that's a followed by space), I see "~/a [No matches]". Even typing "a
> b/" gives me "~/a b/  [No matches]", and neither TAB nor C-M-i
> (icomplete-force-complete) will complete the file "~/a b/c".
> >
> > 3. Menu entries in an info buffer.
> >
> > In emacs -Q use `M-x fido-mode' to activate fido-mode.
> > Use `C-h i' to open the main info directory, pick an entry with a space
> in it. I have a "Date input format" entry from coreutils, for example. Use
> `m' (bound to Info-menu) and type "Date". fido-mode does offer me the
> relevant completions, and in my case, "Date input format" is the only one
> where "Date" is followed by a space. If I type the space nothing happens
> (space is bound to minibuffer-complete-word), no space is entered, the
> candidates don't change. Pressing space again pops up the completions
> buffer.
> >
> > If I use `C-q SPC` to insert a literal space, I get "Date  (No matches)".
> >
> > If I skip the space and keep typing "inpu", it matches "Date input
> format", but pressing TAB to complete it to the full "Date input format"
> again says "(No matches)" ---pressing RET will however open the correct
> manual.
> >
> > ----------
> >
> > This was initially meant to be a bug report for
> `icomplete-fido-backward-updir', whose source code I read (but didn't run).
> It uses `backward-kill-sexp', which means it won't fully go up a directory
> if it has spaces in it. I suggest replacing (backward-kill-sexp 1) with
> (zap-up-to-char -1 ?/), as follows:
> >
> > (defun icomplete-fido-backward-updir ()
> >    "Delete char before or go up directory, like `ido-mode'."
> >    (interactive)
> >    (if (and (eq (char-before) ?/)
> >             (eq (icomplete--category) 'file))
> >        (zap-up-to-char -1 ?/)
> >      (call-interactively 'backward-delete-char)))
> >
> > Before submitting that report I decided to test fido-mode and discovered
> it has more fundamental problems with spaces than that.:)
>
>

[-- Attachment #2: Type: text/html, Size: 4376 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15  0:04   ` João Távora
@ 2020-04-15 15:46     ` João Távora
  2020-04-15 16:02       ` João Távora
  0 siblings, 1 reply; 13+ messages in thread
From: João Távora @ 2020-04-15 15:46 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Omar Antolín Camarena, 40625

[-- Attachment #1: Type: text/plain, Size: 5496 bytes --]

Found these two commits:

commit 6d4d00c63417e3479e978a373f252b9f2709ce39
Author: João Távora <joaotavora@gmail.com>
Date:   Sat Nov 23 00:30:49 2019 +0000

    * lisp/minibuffer.el (completion-flex-nospace): Default to t.

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3499,4 +3499,4 @@
-(defcustom completion-flex-nospace nil
-  "Make flex style fail when a space is found in pattern."
+(defcustom completion-flex-nospace t
+  "Non-nil if `flex' completion rejects spaces in search pattern."
   :version "27.1"
   :type 'boolean)

commit 5a62c4b49ca1ac45d576f55d266750b7d1d6668a
Author: Thierry Volpiatto <thierry.volpiatto@gmail.com>
Date:   Thu Nov 21 20:41:19 2019 +0100

    Add new variable to prevent flex completion style

    matching spaces.  This allows flex style working smoothly with other
    styles like helm using spaces.

    * lisp/minibuffer.el (completion-flex-nospace): New user var.
    (completion-flex-try-completion): Use it.
    (completion-flex-all-completions): Same.

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

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

But it seems reasonable for users that wish to use spaces to
set this to nil, so hopefully the emergency is resolved.  I don't
know what prompted me to default it to t, but I wouldn't be
very quick in reverting it. That said, the "rejection" of space
should be handled differently: I agree this is confusing.

João

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

> This is likely the flex completion style, not fido-mode itself.
>
> I'll look into it.
>
> João
>
> On Wed, Apr 15, 2020, 00:06 Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>> Thanks for the report.
>>
>> I can reproduce all three.
>>
>> FWIW, the "bare" icomplete-mode works fine in these cases.
>>
>> On 14.04.2020 19:01, Omar Antolín Camarena wrote:
>> > Here are 3 scenarios I tested with fido-mode starting from emacs -Q
>> (all of these work perfectly with icomplete):
>> >
>> > 1. Files with spaces.
>> >
>> > Run emacs -Q and use `M-x fido-mode' to activate fido-mode.
>> > Create a file with a space in the name. Use find-file to try to open
>> it. As soon as you have a space in the minibuffer, it says "[No matches]".
>> >
>> > For example, I created a file called "one two", and no other file in my
>> home directory starts with "one". In find-file when I type "one" I see the
>> expected result: "~/one[ two] [Matched]".
>> >
>> > If I press TAB to complete I get "one two [No matches]" (from there I
>> can press RET to open the file, this bug report is about the "[No matches]"
>> which is
>> > clearly wrong).
>> >
>> > If after entering "one" I press space, I get "one  [No matches]", that
>> it, I no longer get offered the "one two" completion.
>> >
>> > 2. Directories with spaces.
>> >
>> > In emacs -Q use `M-x fido-mode' to activate fido-mode.
>> > Create a directory with a space in the name. I created a directory
>> called "a b" and put a file called "c" inside. If I run find-file and type
>> "a " (that's a followed by space), I see "~/a [No matches]". Even typing "a
>> b/" gives me "~/a b/  [No matches]", and neither TAB nor C-M-i
>> (icomplete-force-complete) will complete the file "~/a b/c".
>> >
>> > 3. Menu entries in an info buffer.
>> >
>> > In emacs -Q use `M-x fido-mode' to activate fido-mode.
>> > Use `C-h i' to open the main info directory, pick an entry with a space
>> in it. I have a "Date input format" entry from coreutils, for example. Use
>> `m' (bound to Info-menu) and type "Date". fido-mode does offer me the
>> relevant completions, and in my case, "Date input format" is the only one
>> where "Date" is followed by a space. If I type the space nothing happens
>> (space is bound to minibuffer-complete-word), no space is entered, the
>> candidates don't change. Pressing space again pops up the completions
>> buffer.
>> >
>> > If I use `C-q SPC` to insert a literal space, I get "Date  (No
>> matches)".
>> >
>> > If I skip the space and keep typing "inpu", it matches "Date input
>> format", but pressing TAB to complete it to the full "Date input format"
>> again says "(No matches)" ---pressing RET will however open the correct
>> manual.
>> >
>> > ----------
>> >
>> > This was initially meant to be a bug report for
>> `icomplete-fido-backward-updir', whose source code I read (but didn't run).
>> It uses `backward-kill-sexp', which means it won't fully go up a directory
>> if it has spaces in it. I suggest replacing (backward-kill-sexp 1) with
>> (zap-up-to-char -1 ?/), as follows:
>> >
>> > (defun icomplete-fido-backward-updir ()
>> >    "Delete char before or go up directory, like `ido-mode'."
>> >    (interactive)
>> >    (if (and (eq (char-before) ?/)
>> >             (eq (icomplete--category) 'file))
>> >        (zap-up-to-char -1 ?/)
>> >      (call-interactively 'backward-delete-char)))
>> >
>> > Before submitting that report I decided to test fido-mode and
>> discovered it has more fundamental problems with spaces than that.:)
>>
>>

-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 7105 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15 15:46     ` João Távora
@ 2020-04-15 16:02       ` João Távora
  2020-04-15 16:05         ` Eli Zaretskii
  2020-04-15 17:17         ` Dmitry Gutov
  0 siblings, 2 replies; 13+ messages in thread
From: João Távora @ 2020-04-15 16:02 UTC (permalink / raw)
  To: Dmitry Gutov, Thierry Volpiatto, Eli Zaretskii, Stefan Monnier
  Cc: Omar Antolín Camarena, 40625

[-- Attachment #1: Type: text/plain, Size: 7109 bytes --]

Right, here's the origin of the completion-flex-nospace var.
More people were involved, seems I didn't just pull this out
of thin air :-).

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

The purpose of that variable is to be set to t when the user wants
to add other completion styles after `flex' in the completion-styles
variable.  It doesn't make much sense for fido-mode, because
fido-mode only uses one style by definition.  So maybe fthe
fido-mode UI should force it to nil, much like Helm UI forces
it to t.

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

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

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

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

Also, because flex is a new thing in Emacs 27 anyway,
I propose we do it in the emacs-27 branch.  Eli?

João



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

> Found these two commits:
>
> commit 6d4d00c63417e3479e978a373f252b9f2709ce39
> Author: João Távora <joaotavora@gmail.com>
> Date:   Sat Nov 23 00:30:49 2019 +0000
>
>     * lisp/minibuffer.el (completion-flex-nospace): Default to t.
>
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -3499,4 +3499,4 @@
> -(defcustom completion-flex-nospace nil
> -  "Make flex style fail when a space is found in pattern."
> +(defcustom completion-flex-nospace t
> +  "Non-nil if `flex' completion rejects spaces in search pattern."
>    :version "27.1"
>    :type 'boolean)
>
> commit 5a62c4b49ca1ac45d576f55d266750b7d1d6668a
> Author: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date:   Thu Nov 21 20:41:19 2019 +0100
>
>     Add new variable to prevent flex completion style
>
>     matching spaces.  This allows flex style working smoothly with other
>     styles like helm using spaces.
>
>     * lisp/minibuffer.el (completion-flex-nospace): New user var.
>     (completion-flex-try-completion): Use it.
>     (completion-flex-all-completions): Same.
>
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -3497,0 +3497,4 @@
> +(defcustom completion-flex-nospace nil
> +  "Make flex style fail when a space is found in pattern."
> +  :version "27.1"
> +  :type 'boolean)
>
> I honestly _don't_ remember discussing this (says a lot for for
> the state of my brain lately).
>
> But it seems reasonable for users that wish to use spaces to
> set this to nil, so hopefully the emergency is resolved.  I don't
> know what prompted me to default it to t, but I wouldn't be
> very quick in reverting it. That said, the "rejection" of space
> should be handled differently: I agree this is confusing.
>
> João
>
> On Wed, Apr 15, 2020 at 1:04 AM João Távora <joaotavora@gmail.com> wrote:
>
>> This is likely the flex completion style, not fido-mode itself.
>>
>> I'll look into it.
>>
>> João
>>
>> On Wed, Apr 15, 2020, 00:06 Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>>> Thanks for the report.
>>>
>>> I can reproduce all three.
>>>
>>> FWIW, the "bare" icomplete-mode works fine in these cases.
>>>
>>> On 14.04.2020 19:01, Omar Antolín Camarena wrote:
>>> > Here are 3 scenarios I tested with fido-mode starting from emacs -Q
>>> (all of these work perfectly with icomplete):
>>> >
>>> > 1. Files with spaces.
>>> >
>>> > Run emacs -Q and use `M-x fido-mode' to activate fido-mode.
>>> > Create a file with a space in the name. Use find-file to try to open
>>> it. As soon as you have a space in the minibuffer, it says "[No matches]".
>>> >
>>> > For example, I created a file called "one two", and no other file in
>>> my home directory starts with "one". In find-file when I type "one" I see
>>> the expected result: "~/one[ two] [Matched]".
>>> >
>>> > If I press TAB to complete I get "one two [No matches]" (from there I
>>> can press RET to open the file, this bug report is about the "[No matches]"
>>> which is
>>> > clearly wrong).
>>> >
>>> > If after entering "one" I press space, I get "one  [No matches]", that
>>> it, I no longer get offered the "one two" completion.
>>> >
>>> > 2. Directories with spaces.
>>> >
>>> > In emacs -Q use `M-x fido-mode' to activate fido-mode.
>>> > Create a directory with a space in the name. I created a directory
>>> called "a b" and put a file called "c" inside. If I run find-file and type
>>> "a " (that's a followed by space), I see "~/a [No matches]". Even typing "a
>>> b/" gives me "~/a b/  [No matches]", and neither TAB nor C-M-i
>>> (icomplete-force-complete) will complete the file "~/a b/c".
>>> >
>>> > 3. Menu entries in an info buffer.
>>> >
>>> > In emacs -Q use `M-x fido-mode' to activate fido-mode.
>>> > Use `C-h i' to open the main info directory, pick an entry with a
>>> space in it. I have a "Date input format" entry from coreutils, for
>>> example. Use `m' (bound to Info-menu) and type "Date". fido-mode does offer
>>> me the relevant completions, and in my case, "Date input format" is the
>>> only one where "Date" is followed by a space. If I type the space nothing
>>> happens (space is bound to minibuffer-complete-word), no space is entered,
>>> the candidates don't change. Pressing space again pops up the completions
>>> buffer.
>>> >
>>> > If I use `C-q SPC` to insert a literal space, I get "Date  (No
>>> matches)".
>>> >
>>> > If I skip the space and keep typing "inpu", it matches "Date input
>>> format", but pressing TAB to complete it to the full "Date input format"
>>> again says "(No matches)" ---pressing RET will however open the correct
>>> manual.
>>> >
>>> > ----------
>>> >
>>> > This was initially meant to be a bug report for
>>> `icomplete-fido-backward-updir', whose source code I read (but didn't run).
>>> It uses `backward-kill-sexp', which means it won't fully go up a directory
>>> if it has spaces in it. I suggest replacing (backward-kill-sexp 1) with
>>> (zap-up-to-char -1 ?/), as follows:
>>> >
>>> > (defun icomplete-fido-backward-updir ()
>>> >    "Delete char before or go up directory, like `ido-mode'."
>>> >    (interactive)
>>> >    (if (and (eq (char-before) ?/)
>>> >             (eq (icomplete--category) 'file))
>>> >        (zap-up-to-char -1 ?/)
>>> >      (call-interactively 'backward-delete-char)))
>>> >
>>> > Before submitting that report I decided to test fido-mode and
>>> discovered it has more fundamental problems with spaces than that.:)
>>>
>>>
>
> --
> João Távora
>


-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 9512 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15 16:02       ` João Távora
@ 2020-04-15 16:05         ` Eli Zaretskii
  2020-04-15 17:17         ` Dmitry Gutov
  1 sibling, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2020-04-15 16:05 UTC (permalink / raw)
  To: João Távora; +Cc: omar, dgutov, monnier, 40625, thierry.volpiatto

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 15 Apr 2020 17:02:21 +0100
> Cc: Omar Antolín Camarena <omar@matem.unam.mx>, 
> 	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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15 16:02       ` João Távora
  2020-04-15 16:05         ` Eli Zaretskii
@ 2020-04-15 17:17         ` Dmitry Gutov
  2020-04-15 17:26           ` Omar Antolín Camarena
  2020-04-15 17:44           ` João Távora
  1 sibling, 2 replies; 13+ messages in thread
From: Dmitry Gutov @ 2020-04-15 17:17 UTC (permalink / raw)
  To: João Távora, Thierry Volpiatto, Eli Zaretskii,
	Stefan Monnier
  Cc: Omar Antolín Camarena, 40625

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15 17:17         ` Dmitry Gutov
@ 2020-04-15 17:26           ` Omar Antolín Camarena
  2020-04-15 17:41             ` João Távora
  2020-04-15 17:44           ` João Távora
  1 sibling, 1 reply; 13+ messages in thread
From: Omar Antolín Camarena @ 2020-04-15 17:26 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: 40625, Stefan Monnier, Thierry Volpiatto,
	Omar Antolín Camarena, João Távora

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

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 <dgutov@yandex.ru> wrote:

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


-- 
Omar Antolín Camarena

[-- Attachment #2: Type: text/html, Size: 959 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15 17:26           ` Omar Antolín Camarena
@ 2020-04-15 17:41             ` João Távora
  0 siblings, 0 replies; 13+ messages in thread
From: João Távora @ 2020-04-15 17:41 UTC (permalink / raw)
  To: Omar Antolín Camarena
  Cc: 40625, Dmitry Gutov, Stefan Monnier, Thierry Volpiatto,
	Omar Antolín Camarena

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Wed, Apr 15, 2020 at 6:26 PM Omar Antolín 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ão

[-- Attachment #2: Type: text/html, Size: 1092 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15 17:17         ` Dmitry Gutov
  2020-04-15 17:26           ` Omar Antolín Camarena
@ 2020-04-15 17:44           ` João Távora
  2020-04-15 19:38             ` Dmitry Gutov
  1 sibling, 1 reply; 13+ messages in thread
From: João Távora @ 2020-04-15 17:44 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Omar Antolín Camarena, Stefan Monnier, 40625-done,
	Thierry Volpiatto

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

On Wed, Apr 15, 2020 at 6:17 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> 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.

Done. Closing this.

[-- Attachment #2: Type: text/html, Size: 352 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15 17:44           ` João Távora
@ 2020-04-15 19:38             ` Dmitry Gutov
  2020-04-16  8:39               ` João Távora
  0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Gutov @ 2020-04-15 19:38 UTC (permalink / raw)
  To: 40625, joaotavora, omar

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-15 19:38             ` Dmitry Gutov
@ 2020-04-16  8:39               ` João Távora
  2020-04-16 16:56                 ` Omar Antolín Camarena
  0 siblings, 1 reply; 13+ messages in thread
From: João Távora @ 2020-04-16  8:39 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Omar Antolín Camarena, 40625

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Wed, Apr 15, 2020 at 8:38 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> 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.

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

Sorry Omar, and many thanks,
João

[-- Attachment #2: Type: text/html, Size: 855 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#40625: 28.0.50; fido-mode cannot match candidates containing a space
  2020-04-16  8:39               ` João Távora
@ 2020-04-16 16:56                 ` Omar Antolín Camarena
  0 siblings, 0 replies; 13+ messages in thread
From: Omar Antolín Camarena @ 2020-04-16 16:56 UTC (permalink / raw)
  To: João Távora; +Cc: Omar Antolín Camarena, 40625, Dmitry Gutov

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

>
> Sorry Omar, and many thanks,
> João
>

No problem, and thanks for fixing this so quickly!

>
-- 
Omar Antolín Camarena

[-- Attachment #2: Type: text/html, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-04-16 16:56 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-14 16:01 bug#40625: 28.0.50; fido-mode cannot match candidates containing a space Omar Antolín Camarena
2020-04-14 23:06 ` Dmitry Gutov
2020-04-15  0:04   ` João Távora
2020-04-15 15:46     ` João Távora
2020-04-15 16:02       ` João Távora
2020-04-15 16:05         ` Eli Zaretskii
2020-04-15 17:17         ` Dmitry Gutov
2020-04-15 17:26           ` Omar Antolín Camarena
2020-04-15 17:41             ` João Távora
2020-04-15 17:44           ` João Távora
2020-04-15 19:38             ` Dmitry Gutov
2020-04-16  8:39               ` João Távora
2020-04-16 16:56                 ` Omar Antolín Camarena

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).