[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50470: 27.1; 'company-mode' 'eshell'
From: |
Dmitry Gutov |
Subject: |
bug#50470: 27.1; 'company-mode' 'eshell' |
Date: |
Mon, 24 Jan 2022 03:50:59 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 |
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.