|
From: | Dmitry Gutov |
Subject: | bug#72176: 30.0.60; icomplete-vertical-mode failed to work with Error |
Date: | Sun, 21 Jul 2024 05:27:43 +0300 |
User-agent: | Mozilla Thunderbird |
Hi Eshel, On 20/07/2024 19:48, Eshel Yaron wrote:
Eli Zaretskii <eliz@gnu.org> writes:From: João Távora <joaotavora@gmail.com> Date: Sat, 20 Jul 2024 10:09:38 +0100 Cc: Robert Pluim <rpluim@gmail.com>, 72176@debbugs.gnu.org, aqua0210@foxmail.com, visuweshm@gmail.com On Sat, Jul 20, 2024 at 7:05 AM Eli Zaretskii <eliz@gnu.org> wrote:Adding João, who I think wrote this code.Don't understand root cause, but it's in the whereabouts of the current analysis, yes. I recall regexp is supposed to always match, because it has (presumably) been used for a previous filtering. This breakage would seem to be a consequence of 3b07d33059150 by Eshel Yaron which in turn seems to be fixing something stemming from some feature Dmitry added in 6b7ff60a5e71c in June. I went one commit before that one and the recipe didn't break.Thanks, I'm adding the guilty parties to this discussion.I'm afraid you missed your mark, because AFAICT it is Stefan Monnier that's behind the root cause of this issue, which goes back way before Dmitry's change or mine :)
Thanks for investigating! It might or might not be considered a bug (the behavior had been working out okay before our changes), but your proposal does make it more consistent, so I hope we can use it.
vc-annotate for lines in question points to commit 86957a0cd which references bug#11714. I _haven't_ been able to reproduce it with them commented out now - my guess it's because of the file-name-quote operation that had been added much later (the last comment in the bug mentions that functionality as a hypothetical).
So maybe they really are unnecessary now. Though the quoting-unquoting-requoting stuff is pretty gnarly, so it'd be great to get a go-ahead from Stefan as well.
It is a bug in completion--sifn-requote, that leads to incorrect completion strings to be passed to completion-lazy-hilit. It is not related to icomplete per se. To see the issue, try the following: 1. emacs -Q 2. say C-x C-f, clear the minibuffer, and insert ~/.config/~/f 3. hit ? to pop the completions list 4. see something like: --8<---------------cut here---------------start------------->8--- Click or type M-RET on a completion to select it. Type M-<down> or M-<up> to move point between completions. 6 possible completions: .config/~/foo.json .config/~/foo.org .config/~/foo.php .config/~/foo.py .config/~/foo.py~ .config/~/foo.rs --8<---------------cut here---------------end--------------->8--- Note the incorrect prefix ".config/~/", completions should appear as "foo.json", "foo.org", etc. The following diff fixes this for me (including the icomplete symptom), although I can't claim to fully understand completion--sifn-requote yet: diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 31c365bf850..d0eb6b43c80 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3855,13 +3855,13 @@ completion--sifn-requote ;; Second assumptions: If qpos is far from the end this can be a bit slow, ;; so we speed it up by doing a first loop that skips a word at a time. ;; This word-sized loop is careful not to cut in the middle of env-vars. - (while (let ((boundary (string-match "\\(\\$+{?\\)?\\w+\\W*\\'" qstr))) - (and boundary - (progn - (setq qprefix (substring qstr 0 boundary)) - (string-prefix-p uprefix - (substitute-in-file-name qprefix))))) - (setq qstr qprefix)) + ;; (while (let ((boundary (string-match "\\(\\$+{?\\)?\\w+\\W*\\'" qstr))) + ;; (and boundary + ;; (progn + ;; (setq qprefix (substring qstr 0 boundary)) + ;; (string-prefix-p uprefix + ;; (substitute-in-file-name qprefix))))) + ;; (setq qstr qprefix)) (let ((qpos (length qstr))) (while (and (> qpos 0) (string-prefix-p uprefix
[Prev in Thread] | Current Thread | [Next in Thread] |