GNU bug report logs -
#50470
27.1; 'company-mode' 'eshell'
Previous Next
Reported by: Christophe <ch.bollard <at> laposte.net>
Date: Wed, 8 Sep 2021 06:25:02 UTC
Severity: normal
Found in version 27.1
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50470 in the body.
You can then email your comments to 50470 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Wed, 08 Sep 2021 06:25:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Christophe <ch.bollard <at> laposte.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 08 Sep 2021 06:25:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
when company-mode is activate:
(use-package company
:ensure t
:init
(global-company-mode t)
)
there are some weird things:
- when you type something, if you enter a single quote a blank space is added.
ex: $ ls Images/'
- and it's impossible to use a wildcad (*) if you want for example copy all
.txt file from a directory. And the C-q not working, I have dot do M-x
quoted-insert to insert '*'.
With the 26.1 version of emacs there was a workarround that worked (deactivate
completion at point) but in this actual version that remove all autocompletion
in eshell.
In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
of 2021-03-28, modified by Debian built on x86-conova-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Recent messages:
Making completion list...
You can run the command ‘dired’ with C-x d
Mark saved where search started
Mark set
Making completion list... [3 times]
Quit [2 times]
Making completion list...
Complete, but not unique
Quit
Making completion list...
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 --enable-libsystemd --with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-mailutils --build x86_64-linux-gnu
--prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man
--enable-libsystemd --with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-mailutils --with-cairo --with-x=yes
--with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
-ffile-prefix-map=/build/emacs-LlFm6W/emacs-27.1+1=. -fstack-protector-strong
-Wformat -Werror=format-security -Wall' '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 LIBSYSTEMD JSON PDUMPER
LCMS2 GMP
Important settings:
value of $LANG: fr_FR.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Eshell
Minor modes in effect:
pyvenv-mode: t
shell-dirtrack-mode: t
show-paren-mode: t
global-flycheck-mode: t
global-company-mode: t
company-mode: t
xclip-mode: t
global-subword-mode: t
subword-mode: t
display-time-mode: t
display-battery-mode: t
electric-pair-mode: t
server-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-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
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-site hides /usr/share/emacs/site-lisp/tex-site
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/auctex hides /usr/share/emacs/site-lisp/auctex
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/preview hides /usr/share/auctex/preview
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/font-latex hides /usr/share/auctex/font-latex
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-buf hides /usr/share/auctex/tex-buf
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex hides /usr/share/auctex/tex
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-style hides /usr/share/auctex/tex-style
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/bib-cite hides /usr/share/auctex/bib-cite
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/multi-prompt hides /usr/share/auctex/multi-prompt
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/context hides /usr/share/auctex/context
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/context-nl hides /usr/share/auctex/context-nl
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-mik hides /usr/share/auctex/tex-mik
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-bar hides /usr/share/auctex/tex-bar
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-font hides /usr/share/auctex/tex-font
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/latex hides /usr/share/auctex/latex
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-fold hides /usr/share/auctex/tex-fold
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/latex-flymake hides /usr/share/auctex/latex-flymake
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-jp hides /usr/share/auctex/tex-jp
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/plain-tex hides /usr/share/auctex/plain-tex
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-ispell hides /usr/share/auctex/tex-ispell
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/texmathp hides /usr/share/auctex/texmathp
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/toolbar-x hides /usr/share/auctex/toolbar-x
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/context-en hides /usr/share/auctex/context-en
/home/mutenroshii/.emacs.d/elpa/auctex-13.0.14/tex-info hides /usr/share/auctex/tex-info
Features:
(shadow mailalias emacsbug sendmail misearch multi-isearch dired-aux em-unix
em-script em-prompt em-ls em-hist em-pred em-glob em-dirs esh-var em-cmpl
em-basic em-banner em-alias esh-mode flyspell ispell .emacs programmation
ac-geiser geiser-guile info-look geiser geiser-repl geiser-image geiser-company
geiser-doc geiser-menu geiser-edit geiser-completion geiser-autodoc geiser-eval
geiser-connection tq geiser-syntax scheme geiser-log geiser-popup view
py-autopep8 yasnippet highlight-indentation flymake-proc flymake warnings elpy
elpy-rpc pyvenv elpy-shell elpy-profile elpy-django s elpy-refactor diff-mode
easy-mmode python tramp-sh tramp tramp-loaddefs trampver tramp-integration
tramp-compat shell pcomplete parse-time iso8601 ls-lisp grep files-x blacken
jedi jedi-core python-environment epc ctable concurrent deferred auto-complete
popup virtualenv ada-mode align ada-skel wisi-skel ada-process
wisi-process-parse ada-indent-user-options ada-core wisi-prj wisi wisi-fringe
wisi-parse-common semantic/lex semantic/fw mode-local uniquify-files find-file
compile skeleton paren flycheck find-func rx dash elfeed-show elfeed-search
bookmark pp shr svg dom elfeed-csv elfeed elfeed-curl elfeed-log elfeed-db
elfeed-lib thingatpt avl-tree url-queue xml-query xml em-term eshell esh-cmd
esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util
company-oddmuse company-keywords company-etags etags fileloop generator xref
project company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-capf company-cmake company-semantic company-template
company-bbdb company pcase ido cus-edit cus-start cus-load wid-edit xclip linum
cap-words superword subword time battery sr-speedbar speedbar sb-image ezimage
dframe elec-pair multi-term advice term disp-table comint ansi-color ehelp
edmacro kmacro akira-theme exec-path-from-shell cl-extra use-package-ensure
use-package-core server mm-archive message dired dired-loaddefs format-spec
rfc822 mml mml-sec epa derived gnus-util rmail rmail-loaddefs
text-property-search time-date mailabbrev gmm-utils mailheader mm-decode
mm-bodies mm-encode mail-utils gnutls network-stream url-http mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc puny
url-cache url-auth url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap epg epg-config finder-inf preview-latex
tex-site geiser-impl help-fns radix-tree help-mode geiser-custom geiser-base
ring 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 497748 27141)
(symbols 48 32295 1)
(strings 32 157981 6846)
(string-bytes 1 4388026)
(vectors 16 49196)
(vector-slots 8 578680 43664)
(floats 8 193 258)
(intervals 56 551 184)
(buffers 1000 13))
--
Christophe BOLLARD
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Wed, 08 Sep 2021 16:02:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Hello,
in fact when I run emacs -Q there is the '*' issue.
It's impossible to type the wikdcard character after a directory's name, so it
--
Christophe BOLLARD
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Wed, 08 Sep 2021 16:08:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Sorry I made a mistake with the last message.
I said, even while running emacs with the -Q argument, it's impossible to type
the wildcard character (following a directory's name)
--
Christophe BOLLARD
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Thu, 09 Sep 2021 01:58:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Hi!
On 08.09.2021 09:23, Christophe via Bug reports for GNU Emacs, the Swiss
army knife of text editors wrote:
> Hello,
> when company-mode is activate:
> (use-package company
> :ensure t
> :init
> (global-company-mode t)
> )
> there are some weird things:
> - when you type something, if you enter a single quote a blank space is added.
> ex: $ ls Images/'
This is unfortunately an old problem. I though there was already a bug
report for it, but couldn't find it. Hope someone will find time to dig
in through the leaky abstraction of c-a-p-f -> pcomplete.
> - and it's impossible to use a wildcad (*) if you want for example copy all
> .txt file from a directory. And the C-q not working, I have dot do M-x
> quoted-insert to insert '*'.
That sounds like bug#18951. But it was fixed, though. Maybe some minor
variation of it?
> With the 26.1 version of emacs there was a workarround that worked (deactivate
> completion at point) but in this actual version that remove all autocompletion
> in eshell.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Thu, 09 Sep 2021 05:49:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Maybe the debian version was frozen befor the fix then.
--
Christophe BOLLARD
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Thu, 09 Sep 2021 12:07:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 09.09.2021 08:48, Christophe wrote:
> Maybe the debian version was frozen befor the fix then.
That's very unlikely. And the fix was in 26.1 even, not 27.
You can jump to your sources and see whether the commit
(https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5d744e032fee9ce60446a3cc0cf7c2e681ace465)
it applied anyway.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Thu, 09 Sep 2021 13:10:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Exact. So I don't know why I cannot use the wildcards without that is replace
by pcomplete.
I'll going on searching a solution, I can't give up eshell like this.
--
Christophe BOLLARD
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Thu, 09 Sep 2021 23:31:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 09.09.2021 16:09, Christophe wrote:
> Exact. So I don't know why I cannot use the wildcards without that is replace
> by pcomplete.
> I'll going on searching a solution, I can't give up eshell like this.
Until this is fixed, you can disable pcomplete <-> capf intergration in
eshell like this:
(defun my/disable-pcomplete-capf ()
(remove-hook 'completion-at-point-functions
#'pcomplete-completions-at-point
t))
(add-hook 'eshell-mode-hook #'my/disable-pcomplete-capf)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Fri, 10 Sep 2021 05:13:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 50470 <at> debbugs.gnu.org (full text, mbox):
I used something like this in the 26.1 (I've found in a site stackoverflow or stackexchange):
(defun my-eshell-remove-pcomplete ()
"Remove anoying tab insert when no completion found by company."
(remove-hook 'completion-at-point-functions #'pcomplete-completions-at-point t))
(add-hook 'eshell-mode-hook #'my-eshell-remove-pcomplete)
And like yours, actually if I use this I have no more autocompletion in eshell.
(Except fore the path if that start by ./)
So I have to add this now:
(add-hook 'eshell-mode-hook
(lambda ()
(define-key eshell-mode-map (kbd "<tab>")
(lambda () (interactive) (pcomplete-std-complete)))))
But that's less efficient.
(except for the wildcards and the blank spaces that's appears after single and
double quotes)
Thanks for the time spent on this, at least I have no more blank
spaces/wildcards issues and I can use the tab for the autocompletion.
--
Christophe BOLLARD
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sun, 05 Dec 2021 22:08:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 09.09.2021 04:57, Dmitry Gutov wrote:
> Hi!
>
> On 08.09.2021 09:23, Christophe via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>> Hello,
>> when company-mode is activate:
>> (use-package company
>> :ensure t
>> :init
>> (global-company-mode t)
>> )
>> there are some weird things:
>> - when you type something, if you enter a single quote a blank space
>> is added.
>> ex: $ ls Images/'
>
> This is unfortunately an old problem. I though there was already a bug
> report for it, but couldn't find it. Hope someone will find time to dig
> in through the leaky abstraction of c-a-p-f -> pcomplete.
Some new details, from
https://github.com/company-mode/company-mode/discussions/1276:
When this happens (the user types a quote character and the tab
character is inserted), there is a message in the echo area:
Completion function pcomplete-completions-at-point uses a deprecated
calling convention
I'm going to add Stefan to Cc in case maybe he had a quick fix in mind,
since I saw him reply to a similar-ish bug report about pcomplete
integration.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Fri, 10 Dec 2021 10:46:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 09.09.2021 04:57, Dmitry Gutov wrote:
>> Hi!
>>
>> On 08.09.2021 09:23, Christophe via Bug reports for GNU Emacs, the Swiss
>> army knife of text editors wrote:
>>> Hello,
>>> when company-mode is activate:
>>> (use-package company
>>> :ensure t
>>> :init
>>> (global-company-mode t)
>>> )
>>> there are some weird things:
>>> - when you type something, if you enter a single quote a blank space
>>> is added.
>>> ex: $ ls Images/'
>>
>> This is unfortunately an old problem. I though there was already a bug
>> report for it, but couldn't find it. Hope someone will find time to dig
>> in through the leaky abstraction of c-a-p-f -> pcomplete.
>
> Some new details, from
> https://github.com/company-mode/company-mode/discussions/1276:
>
> When this happens (the user types a quote character and the tab
> character is inserted),
In my package capf-autosuggest, I run completion-at-point-functions
somewhat like this:
(let (;; `pcomplete-completions-at-point' may illegally use
;; `completion-in-region' itself instead of returning a collection.
;; Let's try to outsmart it.
(completion-in-region-function
(lambda (start end collection predicate)
(throw 'illegal-comp-in-region
(list start end collection :predicate predicate))))
;; Prevent `pcomplete-completions-at-point' from inserting a TAB
(buffer-read-only t))
;; `ielm-complete-filename' may illegaly move point
(save-excursion
(condition-case nil
(catch 'illegal-comp-in-region
(run-hook-wrapped 'completion-at-point-functions ...))
(buffer-read-only nil))))
This way, old style capf functions are prevented from inserting a TAB or
moving point.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Fri, 10 Dec 2021 13:11:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 50470 <at> debbugs.gnu.org (full text, mbox):
> In my package capf-autosuggest, I run completion-at-point-functions
> somewhat like this:
>
> (let (;; `pcomplete-completions-at-point' may illegally use
> ;; `completion-in-region' itself instead of returning a collection.
> ;; Let's try to outsmart it.
> (completion-in-region-function
> (lambda (start end collection predicate)
> (throw 'illegal-comp-in-region
> (list start end collection :predicate predicate))))
> ;; Prevent `pcomplete-completions-at-point' from inserting a TAB
> (buffer-read-only t))
> ;; `ielm-complete-filename' may illegaly move point
> (save-excursion
> (condition-case nil
> (catch 'illegal-comp-in-region
> (run-hook-wrapped 'completion-at-point-functions ...))
> (buffer-read-only nil))))
>
> This way, old style capf functions are prevented from inserting a TAB or
> moving point.
Hmm... capf itself tries to "solve" that problem in the following way:
(defvar completion--capf-misbehave-funs nil
"List of functions found on `completion-at-point-functions' that misbehave.
These are functions that neither return completion data nor a completion
function but instead perform completion right away.")
(defvar completion--capf-safe-funs nil
"List of well-behaved functions found on `completion-at-point-functions'.
These are functions which return proper completion data rather than
a completion function or god knows what else.")
(defun completion--capf-wrapper (fun which)
;; FIXME: The safe/misbehave handling assumes that a given function will
;; always return the same kind of data, but this breaks down with functions
;; like comint-completion-at-point or mh-letter-completion-at-point, which
;; could be sometimes safe and sometimes misbehaving (and sometimes neither).
(if (pcase which
('all t)
('safe (member fun completion--capf-safe-funs))
('optimist (not (member fun completion--capf-misbehave-funs))))
(let ((res (funcall fun)))
(cond
((and (consp res) (not (functionp res)))
(unless (member fun completion--capf-safe-funs)
(push fun completion--capf-safe-funs))
(and (eq 'no (plist-get (nthcdr 3 res) :exclusive))
;; FIXME: Here we'd need to decide whether there are
;; valid completions against the current text. But this depends
;; on the actual completion UI (e.g. with the default completion
;; it depends on completion-style) ;-(
;; We approximate this result by checking whether prefix
;; completion might work, which means that non-prefix completion
;; will not work (or not right) for completion functions that
;; are non-exclusive.
(null (try-completion (buffer-substring-no-properties
(car res) (point))
(nth 2 res)
(plist-get (nthcdr 3 res) :predicate)))
(setq res nil)))
((not (or (listp res) (functionp res)))
(unless (member fun completion--capf-misbehave-funs)
(message
"Completion function %S uses a deprecated calling convention" fun)
(push fun completion--capf-misbehave-funs))))
(if res (cons fun res)))))
(defun completion-at-point ()
"Perform completion on the text around point.
The completion method is determined by `completion-at-point-functions'."
(interactive)
(let ((res (run-hook-wrapped 'completion-at-point-functions
#'completion--capf-wrapper 'all)))
...))
Maybe this should be improved/refined?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Mon, 13 Dec 2021 02:47:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 10.12.2021 16:10, Stefan Monnier wrote:
> Hmm... capf itself tries to "solve" that problem in the following way:
The problem with this approach is that pcomplete-completion-at-point
behaves properly most of the time, and only "misbehaves" after some
particular inputs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Mon, 13 Dec 2021 03:16:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov [2021-12-13 05:45:01] wrote:
> On 10.12.2021 16:10, Stefan Monnier wrote:
>> Hmm... capf itself tries to "solve" that problem in the following way:
> The problem with this approach is that pcomplete-completion-at-point behaves
> properly most of the time, and only "misbehaves" after some
> particular inputs.
The quotes around "solve" intended to say that I'm quite aware it's not
a full solution. But it's also not cast in stone. So whichever
better/additional workaround you come up with might be welcome in
`minibuffer.el`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sun, 23 Jan 2022 03:24:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 50470 <at> debbugs.gnu.org (full text, mbox):
> Some new details, from
> https://github.com/company-mode/company-mode/discussions/1276:
>
> When this happens (the user types a quote character and the tab character is
> inserted), there is a message in the echo area:
>
> Completion function pcomplete-completions-at-point uses a deprecated
> calling convention
>
> I'm going to add Stefan to Cc in case maybe he had a quick fix in mind,
> since I saw him reply to a similar-ish bug report about
> pcomplete integration.
I think I managed to reproduce the problem and get a good backtrace for
the above with:
src/emacs -Q -l .../company/company-autoloads.el \
-f eshell -f company-mode \
--eval '(advice-add `pcomplete-completions-at-point :around (lambda (orig-fun &rest args) (let ((buffer-read-only t) (debug-on-signal t)) (apply orig-fun args))))' \
--eval '(setq debug-on-error t debug-on-signal nil debug-ignored-errors nil)' \
-l company.el \
--eval "(progn (sit-for 1) (insert \"echo '\") \
(company-idle-begin (current-buffer) \
(selected-window)\
(buffer-chars-modified-tick)\
(point)))"
And the 100% untested patch below is a suggestion for how to try and fix
those kinds of bugs.
Can someone try and maybe make it work?
Stefan
diff --git a/lisp/eshell/em-cmpl.el b/lisp/eshell/em-cmpl.el
index c6a51b1793..bc35c92493 100644
--- a/lisp/eshell/em-cmpl.el
+++ b/lisp/eshell/em-cmpl.el
@@ -311,18 +311,24 @@ eshell-completion-help
(describe-prefix-bindings)
(call-interactively 'pcomplete-help)))
+(defun eshell--pcomplete-insert-tab ()
+ (if (not pcomplete-allow-modifications)
+ (throw 'pcompleted nil)
+ (insert-and-inherit "\t")
+ (throw 'pcompleted t)))
+
(defun eshell-complete-parse-arguments ()
"Parse the command line arguments for `pcomplete-argument'."
(when (and eshell-no-completion-during-jobs
(eshell-interactive-process))
- (insert-and-inherit "\t")
- (throw 'pcompleted t))
+ (eshell--pcomplete-insert-tab))
(let ((end (point-marker))
(begin (save-excursion (eshell-bol) (point)))
(posns (list t))
args delim)
- (when (memq this-command '(pcomplete-expand
- pcomplete-expand-and-complete))
+ (when (and pcomplete-allow-modifications
+ (memq this-command '(pcomplete-expand
+ pcomplete-expand-and-complete)))
(run-hook-with-args 'eshell-expand-input-functions begin end)
(if (= begin end)
(end-of-line))
@@ -335,14 +341,11 @@ eshell-complete-parse-arguments
(setq begin (1+ (cadr delim))
args (eshell-parse-arguments begin end)))
((eq (car delim) ?\()
- (eshell-complete-lisp-symbol)
- (throw 'pcompleted t))
+ (throw 'pcompleted (elisp-completion-at-point)))
(t
- (insert-and-inherit "\t")
- (throw 'pcompleted t))))
+ (eshell--pcomplete-insert-tab))))
(when (get-text-property (1- end) 'comment)
- (insert-and-inherit "\t")
- (throw 'pcompleted t))
+ (eshell--pcomplete-insert-tab))
(let ((pos begin))
(while (< pos end)
(if (get-text-property pos 'arg-begin)
diff --git a/lisp/pcomplete.el b/lisp/pcomplete.el
index 289312e0bb..f9c5b00719 100644
--- a/lisp/pcomplete.el
+++ b/lisp/pcomplete.el
@@ -189,6 +189,16 @@ pcomplete-expand-before-complete
`pcomplete-parse-arguments-function'."
:type 'boolean)
+(defvar pcomplete-allow-modifications nil
+ "If non-nil, allow effects in `pcomplete-parse-arguments-function'.
+For the `pcomplete' command, it was common for functions in
+`pcomplete-parse-arguments-function' to make modifications to the
+buffer, like expanding variables are such.
+For `completion-at-point-functions', this is not an option any more, so
+this variable is used to tell `pcomplete-parse-arguments-function'
+whether it can do the modifications like it used to, or whether
+it should refrain from doing so.")
+
(defcustom pcomplete-parse-arguments-function
#'pcomplete-parse-buffer-arguments
"A function to call to parse the current line's arguments.
@@ -392,6 +402,9 @@ pcomplete-completions-at-point
;; imposing the pcomplete UI over the standard UI.
(catch 'pcompleted
(let* ((pcomplete-stub)
+ (buffer-read-only
+ ;; Make sure the function obeys `pcomplete-allow-modifications'.
+ (if pcomplete-allow-modifications buffer-read-only t))
pcomplete-seen pcomplete-norm-func
pcomplete-args pcomplete-last pcomplete-index
(pcomplete-autolist pcomplete-autolist)
@@ -526,6 +539,7 @@ pcomplete
pcomplete-last-completion-raw nil)
(catch 'pcompleted
(let* ((pcomplete-stub)
+ (pcomplete-allow-modifications t)
pcomplete-seen pcomplete-norm-func
pcomplete-args pcomplete-last pcomplete-index
(pcomplete-autolist pcomplete-autolist)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Mon, 24 Jan 2022 01:52:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Hi Stefan,
On 23.01.2022 05:23, Stefan Monnier wrote:
> And the 100% untested patch below is a suggestion for how to try and fix
> those kinds of bugs.
> Can someone try and maybe make it work?
I've tried the patch, and it seems to work already, as well as fix this
particular scenario. (Thanks!)
Might as well install it, I think.
There is a scenario that is more noticeably broken (yet actually better
with this patch): a modification of bug#18951. Instead of
ls *
try
ls ~/Docu*
...and [on master] the result is that the asterisk is replaced with the
"common part" of the possible completions automatically. If there is
nothing to expand with, the asterisk is similarly deleted.
With your patch, we get the "Buffer is read-only" error in *Messages*
instead, which is probably an improvement. Because it doesn't modify the
input, nor break Company completions long-term (after the asterisk is
removed).
The offending functions is pcomplete-parse-arguments. There is some
complex global state going on there, but the following addition seems to
fix the problem:
@@ -790,6 +804,9 @@ pcomplete-parse-arguments
(common-stub (car completions))
(c completions)
(len (length common-stub)))
+ (unless pcomplete-allow-modifications
+ (setq pcomplete-stub (buffer-substring begin (point)))
+ (throw 'pcomplete-completions completions))
(while (and c (> len 0))
(while (and (> len 0)
(not (string=
Not sure if this new value of pcomplete-stub is always TRT, but it has
passed a bunch of my experiments successfully.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 25 Jan 2022 23:07:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Hi John,
Could you explain to me some of the code of `pcomplete-parse-arguments`?
I know that was many years ago but hopefully there's still some fond
memories of how you designed it.
To be honest, the only part I sort-of understand are the first
5-6 lines. Then comes the `(let ((begin (pcomplete-begin 'last)))` and
after that I'm lost: it doesn't look like we're parsing arguments
any more.
E.g. Why/when would pcomplete-stub contain a list rather than a string?
Stefan
Dmitry Gutov [2022-01-24 03:50:59] wrote:
> Hi Stefan,
>
> On 23.01.2022 05:23, Stefan Monnier wrote:
>> And the 100% untested patch below is a suggestion for how to try and fix
>> those kinds of bugs.
>> Can someone try and maybe make it work?
>
> I've tried the patch, and it seems to work already, as well as fix this
> particular scenario. (Thanks!)
>
> Might as well install it, I think.
>
> There is a scenario that is more noticeably broken (yet actually better with
> this patch): a modification of bug#18951. Instead of
>
> ls *
>
> try
>
> ls ~/Docu*
>
> ...and [on master] the result is that the asterisk is replaced with the
> "common part" of the possible completions automatically. If there is
> nothing to expand with, the asterisk is similarly deleted.
>
> With your patch, we get the "Buffer is read-only" error in *Messages*
> instead, which is probably an improvement. Because it doesn't modify the
> input, nor break Company completions long-term (after the asterisk is
> removed).
>
> The offending functions is pcomplete-parse-arguments. There is some complex
> global state going on there, but the following addition seems to fix the
> problem:
>
> @@ -790,6 +804,9 @@ pcomplete-parse-arguments
> (common-stub (car completions))
> (c completions)
> (len (length common-stub)))
> + (unless pcomplete-allow-modifications
> + (setq pcomplete-stub (buffer-substring begin (point)))
> + (throw 'pcomplete-completions completions))
> (while (and c (> len 0))
> (while (and (> len 0)
> (not (string=
>
>
> Not sure if this new value of pcomplete-stub is always TRT, but it has
> passed a bunch of my experiments successfully.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sat, 04 Jun 2022 22:30:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 50470 <at> debbugs.gnu.org (full text, mbox):
It seems like this bug was fixed in bug#55204?
Or at least the problems scenarios are not reproducible anymore.
The downside compared to my latest patch is that it actually expanded
~/Downl* into a bunch of completions (and the current behavior is "no
completions"), but that seems minor.
It might be considered a regression, though.
On 26.01.2022 01:05, Stefan Monnier wrote:
> Hi John,
>
> Could you explain to me some of the code of `pcomplete-parse-arguments`?
> I know that was many years ago but hopefully there's still some fond
> memories of how you designed it.
>
> To be honest, the only part I sort-of understand are the first
> 5-6 lines. Then comes the `(let ((begin (pcomplete-begin 'last)))` and
> after that I'm lost: it doesn't look like we're parsing arguments
> any more.
>
> E.g. Why/when would pcomplete-stub contain a list rather than a string?
>
>
> Stefan
>
>
> Dmitry Gutov [2022-01-24 03:50:59] wrote:
>
>> Hi Stefan,
>>
>> On 23.01.2022 05:23, Stefan Monnier wrote:
>>> And the 100% untested patch below is a suggestion for how to try and fix
>>> those kinds of bugs.
>>> Can someone try and maybe make it work?
>>
>> I've tried the patch, and it seems to work already, as well as fix this
>> particular scenario. (Thanks!)
>>
>> Might as well install it, I think.
>>
>> There is a scenario that is more noticeably broken (yet actually better with
>> this patch): a modification of bug#18951. Instead of
>>
>> ls *
>>
>> try
>>
>> ls ~/Docu*
>>
>> ...and [on master] the result is that the asterisk is replaced with the
>> "common part" of the possible completions automatically. If there is
>> nothing to expand with, the asterisk is similarly deleted.
>>
>> With your patch, we get the "Buffer is read-only" error in *Messages*
>> instead, which is probably an improvement. Because it doesn't modify the
>> input, nor break Company completions long-term (after the asterisk is
>> removed).
>>
>> The offending functions is pcomplete-parse-arguments. There is some complex
>> global state going on there, but the following addition seems to fix the
>> problem:
>>
>> @@ -790,6 +804,9 @@ pcomplete-parse-arguments
>> (common-stub (car completions))
>> (c completions)
>> (len (length common-stub)))
>> + (unless pcomplete-allow-modifications
>> + (setq pcomplete-stub (buffer-substring begin (point)))
>> + (throw 'pcomplete-completions completions))
>> (while (and c (> len 0))
>> (while (and (> len 0)
>> (not (string=
>>
>>
>> Not sure if this new value of pcomplete-stub is always TRT, but it has
>> passed a bunch of my experiments successfully.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sun, 05 Jun 2022 00:18:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 50470 <at> debbugs.gnu.org (full text, mbox):
> The downside compared to my latest patch is that it actually expanded
> ~/Downl* into a bunch of completions (and the current behavior is "no
> completions"), but that seems minor.
>
> It might be considered a regression, though.
AFAIK it is a regression, indeed. I thought you'd install your patch
on top. Any reason why you refrained from doing so?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sun, 05 Jun 2022 00:37:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 05.06.2022 03:17, Stefan Monnier wrote:
>> The downside compared to my latest patch is that it actually expanded
>> ~/Downl* into a bunch of completions (and the current behavior is "no
>> completions"), but that seems minor.
>>
>> It might be considered a regression, though.
> AFAIK it is a regression, indeed. I thought you'd install your patch
> on top. Any reason why you refrained from doing so?
Erm, I missed the time when you installed yours: you never wrote about
it here, and my "Emacs Diffs" folder still has 738 unread messages.
So I figured the fix is due to another bug report and patch. :-/
My patch doesn't help with the 'cd ~/Down*' behavior, though: when I
worked on it, pressing C-M-i did expand it as expected, it was mostly
problematic with company-mode (and other similar frontends).
But now C-M-i results in "No match" as well, with or without my patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sun, 05 Jun 2022 00:54:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 50470 <at> debbugs.gnu.org (full text, mbox):
> Erm, I missed the time when you installed yours: you never wrote about
> it here,
Indeed, I had lost track of this bug (and couldn't find your patch when
I looked for it, probably for the same reason).
> and my "Emacs Diffs" folder still has 738 unread messages.
And you're still here chatting?
Kids these days!
> My patch doesn't help with the 'cd ~/Down*' behavior, though: when I worked
> on it, pressing C-M-i did expand it as expected, it was mostly problematic
> with company-mode (and other similar frontends).
>
> But now C-M-i results in "No match" as well, with or without my patch.
Hmm... looks like my lack of understanding of this pcomplete code
strikes again.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sun, 05 Jun 2022 23:46:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 05.06.2022 03:53, Stefan Monnier via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
>> Erm, I missed the time when you installed yours: you never wrote about
>> it here,
>
> Indeed, I had lost track of this bug (and couldn't find your patch when
> I looked for it, probably for the same reason).
>
>> and my "Emacs Diffs" folder still has 738 unread messages.
>
> And you're still here chatting?
> Kids these days!
Aye-aye, cap'n!
>> My patch doesn't help with the 'cd ~/Down*' behavior, though: when I worked
>> on it, pressing C-M-i did expand it as expected, it was mostly problematic
>> with company-mode (and other similar frontends).
>>
>> But now C-M-i results in "No match" as well, with or without my patch.
>
> Hmm... looks like my lack of understanding of this pcomplete code
> strikes again.
Debugging shows that COMPLETIONS just before the bit of code I added
gets set to absolute file names. E.g. if I'm typing
cd ~/Do*
COMPLETIONS is '("/home/dgutov/Documents" "/home/dgutov/Downloads"),
which fails to match "~/Do" because we do prefix-matching by default.
I suppose whatever code does the expansion here, shouldn't
dis-abbreviate the file name (or resolve symlinks, etc). I could find
where that logic resides, though.
Another issue which made investigating this harder, is that eshell-mode
(and only it) has 'C-M-i' bound to eshell-complete-lisp-symbol.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sun, 05 Jun 2022 23:54:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 50470 <at> debbugs.gnu.org (full text, mbox):
> My patch doesn't help with the 'cd ~/Down*' behavior, though: when I worked
> on it, pressing C-M-i did expand it as expected, it was mostly problematic
> with company-mode (and other similar frontends).
>
> But now C-M-i results in "No match" as well, with or without my patch.
AFAICT the "no match" is because we have "~/Down*" as the pattern and
"/home/<foo>/Downloads" as one of the proposed completions, and the
completion style has no idea how the two can match since it doesn't know
we're dealing with files.
In any case, I think your change is going in the right direction, so
I installed a patch which does basically the same.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Mon, 06 Jun 2022 01:35:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 50470 <at> debbugs.gnu.org (full text, mbox):
> Debugging shows that COMPLETIONS just before the bit of code I added gets
> set to absolute file names. E.g. if I'm typing
[ I see we got back to this issue at the very same time :-) ]
> cd ~/Do*
>
> COMPLETIONS is '("/home/dgutov/Documents" "/home/dgutov/Downloads"), which
> fails to match "~/Do" because we do prefix-matching by default.
Yup. We could try and handle this with a `completion-table-subvert`
hack like we do in `pcomplete-completions-at-point`.
Still, if you remove the ~/ the behavior is still not great: it seems I get
"Do*" completed to "Documents/ " where the SPC might not be what I want.
Maybe we should return a special completion-table which implements the
`backend` style.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Mon, 06 Jun 2022 09:09:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 06.06.2022 04:34, Stefan Monnier via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> Still, if you remove the ~/ the behavior is still not great: it seems I get
> "Do*" completed to "Documents/ " where the SPC might not be what I want.
I think that space comes from exit-function (defined at the end of
pcomplete-completions-at-point).
So it should be orthogonal to the contents of the completion table.
The file names in COMPLETIONS inside pcomplete-parse-arguments come
without trailing space.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 07 Jun 2022 15:53:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 50470 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov [2022-06-06 12:07:58] wrote:
> On 06.06.2022 04:34, Stefan Monnier via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>> Still, if you remove the ~/ the behavior is still not great: it seems I get
>> "Do*" completed to "Documents/ " where the SPC might not be what I want.
>
> I think that space comes from exit-function (defined at the end of
> pcomplete-completions-at-point).
> So it should be orthogonal to the contents of the completion table.
Right, but when we complete file names in Eshell, the behavior is
better, because the exit-function is different. I don't think there's
much we can do about it within `pcomplete.el`, tho.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 07 Jun 2022 22:11:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 06.06.2022 02:52, Stefan Monnier wrote:
> In any case, I think your change is going in the right direction, so
> I installed a patch which does basically the same.
I've pushed a fix for that ('pcomplete-completions needs to be a list of
completions AFAICT).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 07 Jun 2022 22:40:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 07.06.2022 18:52, Stefan Monnier wrote:
> Dmitry Gutov [2022-06-06 12:07:58] wrote:
>> On 06.06.2022 04:34, Stefan Monnier via Bug reports for GNU Emacs, the Swiss
>> army knife of text editors wrote:
>>> Still, if you remove the ~/ the behavior is still not great: it seems I get
>>> "Do*" completed to "Documents/ " where the SPC might not be what I want.
>> I think that space comes from exit-function (defined at the end of
>> pcomplete-completions-at-point).
>> So it should be orthogonal to the contents of the completion table.
> Right, but when we complete file names in Eshell, the behavior is
> better, because the exit-function is different. I don't think there's
> much we can do about it within `pcomplete.el`, tho.
I'm sorry, I don't understand.
pcomplete-completions-at-point is the completion function used for
Eshell, and the exit-function it defines at the end is the one that
inserts the spaces.
So... which behaviors are you comparing?
Speaking of trying to use completion-table-subvert, it doesn't seem
obvious which value to use as S2. What we have is a list of strings, and
the common prefix isn't going to always match the (unexpanded) input.
pcomplete-completions-at-point somehow has pcomplete-stub pointing to
the necessary value (e.g. "/home/dgutov/Do") in the asterisk-less cases
(due to some other code path being taken), but not in this specific one.
Conceptually, it seems easier and cleaner to avoid expansion in the
first place. The patch below does that, though I'm not sure what
unwanted side-effects it might have ('cd' still works).
In any case, supporting completion with asterisk doesn't seem very
useful, given that the user might as well omit that char and get the
same list of completions, and typing asterisk in the middle of a work
doesn't work. That's where the 'backend' style could help indeed.
diff --git a/lisp/eshell/em-dirs.el b/lisp/eshell/em-dirs.el
index 5396044d8c..fa504bb618 100644
--- a/lisp/eshell/em-dirs.el
+++ b/lisp/eshell/em-dirs.el
@@ -204,8 +204,8 @@ eshell-dirs-initialize
'eshell-dirs-substitute-cd)
eshell-interpreter-alist)))
- (add-hook 'eshell-parse-argument-hook
- #'eshell-parse-user-reference nil t)
+ ;; (add-hook 'eshell-parse-argument-hook
+ ;; #'eshell-parse-user-reference nil t)
(if (eshell-under-windows-p)
(add-hook 'eshell-parse-argument-hook
#'eshell-parse-drive-letter nil t))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Fri, 17 Mar 2023 06:27:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 50470 <at> debbugs.gnu.org (full text, mbox):
I've recently been digging through how Eshell and Pcomplete interact, so
I think I understand what's happening here.
On 6/7/2022 3:39 PM, Dmitry Gutov wrote:
> pcomplete-completions-at-point somehow has pcomplete-stub pointing to
> the necessary value (e.g. "/home/dgutov/Do") in the asterisk-less cases
> (due to some other code path being taken), but not in this specific one.
I believe the problem is that when Eshell parses the command line to
figure out what to give Pcomplete, it expands the globs itself, so
things get messed up. So we want to prevent glob-expansion before
passing to Pcomplete.
The below patch does this, but it's probably not the right way to do it.
However, it's a simple change, and before I go through the larger
effort of a proper patch, I want to be sure I'm actually solving the
right thing.
For some background/explanation of how I'm thinking we should solve
this: in Emacs 30, while fixing some other completion issues, I added
'eshell-complete--eval-argument-form' (Emacs 29 does a similar thing,
but the code is in 'eshell-complete-parse-arguments'). We probably want
to enhance this function so that it only evaluates Eshell arguments
forms that we know are ok. For a fun example of why the current behavior
is wrong, try pressing TAB at the end of this command: "cd ${sleep 5;
echo Doc}". Yes, it actually *runs* that subcommand before passing it to
Pcomplete. :/
--------------------------------------------------
diff --git a/lisp/eshell/em-cmpl.el b/lisp/eshell/em-cmpl.el
index b65652019d4..7168f91d774 100644
--- a/lisp/eshell/em-cmpl.el
+++ b/lisp/eshell/em-cmpl.el
@@ -325,6 +325,10 @@ eshell-complete-parse-arguments
(if (= begin end)
(end-of-line))
(setq end (point-marker)))
+ ;; Don't expand globs when parsing arguments; we want to pass any
+ ;; globs to Pcomplete unaltered.
+ (let ((eshell-parse-argument-hook (remq #'eshell-parse-glob-chars
+ eshell-parse-argument-hook)))
(if (setq delim
(catch 'eshell-incomplete
(ignore
@@ -341,7 +345,7 @@ eshell-complete-parse-arguments
((member (car delim) '("(" "$("))
(throw 'pcompleted (elisp-completion-at-point)))
(t
- (eshell--pcomplete-insert-tab))))
+ (eshell--pcomplete-insert-tab)))))
(when (get-text-property (1- end) 'comment)
(eshell--pcomplete-insert-tab))
(let ((pos (1- end)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sat, 18 Mar 2023 01:02:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 17/03/2023 08:26, Jim Porter wrote:
> I've recently been digging through how Eshell and Pcomplete interact, so
> I think I understand what's happening here.
Thanks!
> On 6/7/2022 3:39 PM, Dmitry Gutov wrote:
>> pcomplete-completions-at-point somehow has pcomplete-stub pointing to
>> the necessary value (e.g. "/home/dgutov/Do") in the asterisk-less
>> cases (due to some other code path being taken), but not in this
>> specific one.
>
> I believe the problem is that when Eshell parses the command line to
> figure out what to give Pcomplete, it expands the globs itself, so
> things get messed up. So we want to prevent glob-expansion before
> passing to Pcomplete.
>
> The below patch does this, but it's probably not the right way to do it.
> However, it's a simple change, and before I go through the larger
> effort of a proper patch, I want to be sure I'm actually solving the
> right thing.
I can't comment on the exact right way to implement this, but the patch
does seem to solve the remaining problem here. Which is completion for
inputs containing *. The result looks rather nice.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sat, 18 Mar 2023 06:38:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 3/17/2023 6:01 PM, Dmitry Gutov wrote:
> On 17/03/2023 08:26, Jim Porter wrote:
>> The below patch does this, but it's probably not the right way to do
>> it. However, it's a simple change, and before I go through the
>> larger effort of a proper patch, I want to be sure I'm actually
>> solving the right thing.
>
> I can't comment on the exact right way to implement this, but the patch
> does seem to solve the remaining problem here. Which is completion for
> inputs containing *. The result looks rather nice.
Excellent. I'll get to work on a final patch then. I have a pretty good
idea of some ways to implement it, but it'll definitely need some
regression tests to go with it.
Hopefully I can get it finished up over the weekend.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Sun, 19 Mar 2023 18:40:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 50470 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 3/17/2023 11:36 PM, Jim Porter wrote:
> Hopefully I can get it finished up over the weekend.
Ok, here we are. This adds a new defvar called
'eshell-parse-for-completion-p', which Eshell argument parsers can
consult to adjust their behavior. In particular, when that variable is
true, it means a) don't expand globs (let Pcomplete handle that), and b)
return a stub for subcommands and Lisp function forms (we don't want to
execute these inadvertently).
[0001-Avoid-parsing-some-Eshell-forms-when-performing-comp.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Mon, 20 Mar 2023 00:32:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 50470 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 3/19/2023 11:39 AM, Jim Porter wrote:
> Ok, here we are.
Here's an updated patch based on some off-list comments from Stefan.
Most of them are just small doc/naming tweaks, but a couple are worth
mentioning here, I think:
On 3/19/2023 12:15 PM, Stefan Monnier wrote:
>> - (when (memq (char-after) eshell-glob-chars-list)
>> + (when (and (not (bound-and-true-p eshell-parse-for-completion-p))
>
> Can we (cheaply) arrange so that the var is always defined at this
> point (same for the other uses further down in the patch)?
> Maybe by moving the `defvar` elsewhere (e.g. next to
> `eshell-parse-argument-hook`)?
It's a bit ugly, but I'm trying to follow the conventions in Eshell:
since completion is an optional extension module for Eshell, other
modules jump through hoops like this to allow the module to be not-loaded.
Another way to do this (arguably more Eshell-y) would be:
(when (and (eshell-using-module 'eshell-cmpl)
eshell-parsing-for-completion)
But that seemed a little overly-verbose for this...
>> + (if (bound-and-true-p eshell-parse-for-completion-p)
>> + "(unevaluated subcommand)"
>
> Any reason we don't return the actual string that we're trying to
> parse instead (i.e. here, the subcommand)?
I wanted something where we could be pretty sure that Pcomplete wouldn't
treat it specially, since it should be "opaque" to Pcomplete. I changed
this to be a propertized string with just the NUL character:
(propertize "\0" 'eshell-argument-stub TYPE)
That should be pretty unlikely to trigger anything in Pcomplete.
(Arguably, Pcomplete should have some way of marking an argument as "not
real", but I'm not sure anything outside of Eshell would need that...)
[0001-Avoid-parsing-some-Eshell-forms-when-performing-comp.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Mon, 20 Mar 2023 01:36:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 50470 <at> debbugs.gnu.org (full text, mbox):
>> Ok, here we are.
>>> - (when (memq (char-after) eshell-glob-chars-list)
>>> + (when (and (not (bound-and-true-p eshell-parse-for-completion-p))
>>
>> Can we (cheaply) arrange so that the var is always defined at this
>> point (same for the other uses further down in the patch)?
>> Maybe by moving the `defvar` elsewhere (e.g. next to
>> `eshell-parse-argument-hook`)?
>
> It's a bit ugly, but I'm trying to follow the conventions in Eshell: since
> completion is an optional extension module for Eshell, other modules jump
> through hoops like this to allow the module to be not-loaded.
I definitely don't want to force preloading that module.
But maybe that var could have a meaning that's independent
from completion, thus justifying to move it out of the completion
extension module?
E.g. something like "keep parsing free of side effects"? This would also
have the benefit of clarifying the actual meaning of this var: defining
a var based on who uses it or how it's used is always a source of
trouble.
> Another way to do this (arguably more Eshell-y) would be:
>
> (when (and (eshell-using-module 'eshell-cmpl)
> eshell-parsing-for-completion)
`boundp` is definitely much better.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 21 Mar 2023 02:31:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 50470 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 3/19/2023 6:34 PM, Stefan Monnier via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> I definitely don't want to force preloading that module.
> But maybe that var could have a meaning that's independent
> from completion, thus justifying to move it out of the completion
> extension module?
Well, luckily(?) it turns out my patch wasn't quite right anyway, so I
completely rewrote it. (In particular, it didn't correctly generate a
top-level stub if there was a subcommand nested somewhere *inside* an
argument.)
With this change, we now have a more-general way of preventing commands
that can cause side effects: 'eshell-allow-commands'. We can let-bind
that to nil, and then any commands within an argument will signal an error.
Then we just need to disable globbing via a different method (using the
patch I originally posted), and all is well for this bug.
I also added a couple preliminary patches to fix some semi-related
issues I discovered while working on this. These could probably go in a
separate bug, but I'm lazy. ;) The real meat of this change is patch 0003.
[0001-Fix-an-edge-case-in-how-eshell-do-eval-handles-let-b.patch (text/plain, attachment)]
[0002-Simplify-parsing-subcommands-slightly.patch (text/plain, attachment)]
[0003-Avoid-parsing-some-Eshell-forms-when-performing-comp.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 28 Mar 2023 00:42:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 21/03/2023 04:30, Jim Porter wrote:
> On 3/19/2023 6:34 PM, Stefan Monnier via Bug reports for GNU Emacs, the
> Swiss army knife of text editors wrote:
>> I definitely don't want to force preloading that module.
>> But maybe that var could have a meaning that's independent
>> from completion, thus justifying to move it out of the completion
>> extension module?
>
> Well, luckily(?) it turns out my patch wasn't quite right anyway, so I
> completely rewrote it. (In particular, it didn't correctly generate a
> top-level stub if there was a subcommand nested somewhere *inside* an
> argument.)
>
> With this change, we now have a more-general way of preventing commands
> that can cause side effects: 'eshell-allow-commands'. We can let-bind
> that to nil, and then any commands within an argument will signal an error.
>
> Then we just need to disable globbing via a different method (using the
> patch I originally posted), and all is well for this bug.
>
> I also added a couple preliminary patches to fix some semi-related
> issues I discovered while working on this. These could probably go in a
> separate bug, but I'm lazy. 😉 The real meat of this change is patch 0003.
Again, no proper review from me, but I've tried the patches.
Completion looks good, just like with the previous one.
But here's an error I encountered when trying to call a command with
asterisks without expanding them with completion:
$ ls ~/Documents/Sp*
Wrong type argument: stringp, ("~/Documents/Spain/")
This issue is present in master (without the patches applied), but not
in emacs-29.
The patch(es) fix a similar error in company-mode completion --
hopefully the straight evaluation could be fixed as easily.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 28 Mar 2023 04:07:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 3/27/2023 5:41 PM, Dmitry Gutov wrote:
> Again, no proper review from me, but I've tried the patches.
Thanks for taking a look. I'll give it a couple more days in case Stefan
has any thoughts, and if not, I'll merge the patches.
> Completion looks good, just like with the previous one.
>
> But here's an error I encountered when trying to call a command with
> asterisks without expanding them with completion:
>
> $ ls ~/Documents/Sp*
> Wrong type argument: stringp, ("~/Documents/Spain/")
And thanks for catching this. It was fallout from my fix to bug#28064.
I've pushed a fix to master as 28a9438169.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 28 Mar 2023 06:11:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 50470 <at> debbugs.gnu.org (full text, mbox):
> Thanks for taking a look. I'll give it a couple more days in case Stefan has
> any thoughts, and if not, I'll merge the patches.
Sorry, my thoughts have left the building, so just go ahead.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 28 Mar 2023 17:44:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 50470 <at> debbugs.gnu.org (full text, mbox):
> Sorry, my thoughts have left the building, so just go ahead.
Think I saw a few of them jumping over a fence next
to University Ave. They looked to be having fun.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50470; Package
emacs.
(Tue, 28 Mar 2023 19:36:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 50470 <at> debbugs.gnu.org (full text, mbox):
On 3/27/2023 11:10 PM, Stefan Monnier via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
>> Thanks for taking a look. I'll give it a couple more days in case Stefan has
>> any thoughts, and if not, I'll merge the patches.
>
> Sorry, my thoughts have left the building, so just go ahead.
Thanks. Pushed as cde38f0df3f.
Is there anything left to do on this bug now? It seems to me that we
could close it, but I came into this discussion pretty late, so I don't
want to jump the gun...
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
You have taken responsibility.
(Tue, 28 Mar 2023 21:22:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Christophe <ch.bollard <at> laposte.net>:
bug acknowledged by developer.
(Tue, 28 Mar 2023 21:22:01 GMT)
Full text and
rfc822 format available.
Message #127 received at 50470-done <at> debbugs.gnu.org (full text, mbox):
On 28/03/2023 22:35, Jim Porter wrote:
> On 3/27/2023 11:10 PM, Stefan Monnier via Bug reports for GNU Emacs, the
> Swiss army knife of text editors wrote:
>>> Thanks for taking a look. I'll give it a couple more days in case
>>> Stefan has
>>> any thoughts, and if not, I'll merge the patches.
>>
>> Sorry, my thoughts have left the building, so just go ahead.
>
> Thanks. Pushed as cde38f0df3f.
>
> Is there anything left to do on this bug now? It seems to me that we
> could close it, but I came into this discussion pretty late, so I don't
> want to jump the gun...
Looks like there's not.
Everything that I tried, has worked well. Thanks for the fixes! Closing.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 26 Apr 2023 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 364 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.