search

abo-abo / swiper

Ivy - a generic completion frontend for Emacs, Swiper - isearch with an overview, and more. Oh, man!
https://oremacs.com/swiper/
2.32k stars 338 forks source link

Completing a path to executable in eshell messes up the path. #2879

Open iostapyshyn opened 3 years ago

iostapyshyn commented 3 years ago

When completing a path to call an executable, the completion gets inserted at the wrong place after TAB, overwriting the path. Also happens with directories along the way. This doesn't seem happen when completing a path as a part of an argument list.

Screenshots (before and after pressing TAB):

  1. Screen Shot 2021-05-26 at 10 59 10 Screen Shot 2021-05-26 at 10 59 24
  2. Screen Shot 2021-05-26 at 11 01 10 Screen Shot 2021-05-26 at 11 01 13

AFAIR this was working properly before

basil-conto commented 3 years ago

AFAIR this was working properly before

Please be more precise. What version of Ivy are using, on what version of Emacs, and on what platform/OS?

Here's what I'm trying on Ivy commit a5eade0c77b7dd78cdea0f246683c6cb00f7b7c6:

  1. make plain
  2. (let* (dir (clean (lambda () (when dir (delete-directory dir t)))))
 ;; Clean up temporary directory on exit.
 (add-hook 'kill-emacs-hook clean)
 ;; Create temporary parent directory.
 (setq dir (make-temp-file "ivy-" t))
 ;; Create executable file bin/foo under parent directory.
 (let ((exe (expand-file-name "bin/foo" dir)))
   (make-empty-file exe t)
   (set-file-modes exe (file-modes-symbolic-to-number
                        "u+x" (file-modes exe))))
 ;; Start `eshell' in parent directory.
 (let ((default-directory dir))
   (eshell)))
  3. C-x C-e
  4. ./bi TAB
  5. TAB

On Emacs 27 [and 24-26, if I enable lexical-binding in *scratch* and polyfill make-empty-file], step (4) gives ./bin/ and step (5) gives ./bin/foo (as expected).

On Emacs 28, step (4) gives bin/ and step (5) gives bfoo (clearly wrong).

[See below for my exact Emacs versions.]

So to me it looks like something changed upstream that either Ivy isn't handling correctly, or that's a bug.

Can you please help to narrow down what changed for you, and when?

Thanks.

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-05-26 built on tia
Repository revision: 5a762c946eac106e60bb55d8175b32decdbf7d5e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix
In GNU Emacs 27.2.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-05-09 built on tia
Repository revision: 4c3abb3dd105e075bf1cf55e3fe8b5ec2ac8e6cc
Repository branch: wt/emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O0 -g3 -ggdb -gdwarf-4'
 --config-cache --prefix=/home/blc/.local --program-suffix=-27
 --enable-checking=yes,glyphs --enable-check-lisp-object-type
 --with-x-toolkit=lucid --with-file-notification=yes --with-x
 --with-cairo'

Configured features:
XAW3D 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 LUCID X11 XDBE XIM MODULES THREADS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP
basil-conto commented 3 years ago

I've yet to investigate, so I could be completely wrong, but the following upstream changes look relevant:

basil-conto commented 3 years ago

https://git.sv.gnu.org/cgit/emacs.git/commit/?id=82c76e3aeb2465d1d1e66eae5db13ba53e38ed84

It's indeed this change, so I've asked for some clarification upstream: https://lists.gnu.org/r/emacs-devel/2021-05/msg01220.html

iostapyshyn commented 3 years ago

Hello Basil and thank you for looking into this.

I should have been more specific from the start regarding this issue and my versions, sorry for that. I assumed this was related to ivy, but now it's clear for me that this problem appeared when I switched to upstream Emacs. I can also confirm that your snippet yields the exact same behavior you described on Emacs 28 ("bfoo"), which is clearly wrong.

Here's my emacs version:

In GNU Emacs 28.0.50 (build 2, x86_64-apple-darwin20.5.0, NS appkit-2022.50 Version 11.4 (Build 20F71))
 of 2021-05-27 built on mbp-2018.local
Repository revision: f1c3b82d401eecd1facbe0a6c07ccde100ad65d8
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.4

Configured using:
 'configure --with-native-compilation 'CPPFLAGS=
 -I/usr/local/opt/llvm/include' 'LDFLAGS= -L/usr/local/opt/llvm/lib''

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES
NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG THREADS TIFF
TOOLKIT_SCROLL_BARS XIM ZLIB
basil-conto commented 3 years ago

No worries, and thanks for confirming.

I assumed this was related to ivy, but now it's clear for me that this problem appeared when I switched to upstream Emacs.

Right, but since Eshell's new dynamic completion seems to work without Ivy, it's likely that Ivy needs to do something better to support it (Ivy has very limited support for programmed completion in general, see e.g. #2872).

Until I find more time to look into this, I'm hoping someone on emacs-devel will comment on the correctness of Eshell's new table, and also point us in the right direction (I could use all the help I can get with this).

basil-conto commented 3 years ago

It's indeed this change, so I've asked for some clarification upstream: https://lists.gnu.org/r/emacs-devel/2021-05/msg01220.html

Stefan's reply confirms that this can be considered a regression in the development version of Emacs: https://lists.gnu.org/r/emacs-devel/2021-06/msg00254.html

basil-conto commented 3 years ago

I think the same issue has been reported as affecting Company completion at https://bugs.gnu.org/48995.

borysn commented 2 years ago

is there any update on this issue? just started experiencing this with the transition to emacs 28.1 on alpine-linux, using ivy-20220406.1052 from melpa.

played around with this a little today, found that adding an eshell-mode-hook to use the old pcomplete function (deprecated as of emacs v 27.1) with interactive enabled resolves binary path completion errors. not sure what a better temporary fix would be

(add-hook 'eshell-mode-hook
                          (lambda ()
                            (setq eshell-cmpl-cycle-completions nil)
                            (define-key eshell-mode-map (kbd "<tab>")
                              #'(lambda ()
                                  (interactive)
                                  (pcomplete t)))))
minad commented 2 years ago

@borysn This issue is an upstream issue and should be fixed in Emacs itself. You can write a mail to the Emacs bug tracker asking for status updates there (https://bugs.gnu.org/48995). This bug affects all packages which implement completion-at-point: Ivy, Company, Corfu, ...