From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eshel Yaron <me@eshelyaron.com>
Cc: rpluim@gmail.com, "Dmitry Gutov" <dmitry@gutov.dev>,
"João Távora" <joaotavora@gmail.com>,
visuweshm@gmail.com, 72176@debbugs.gnu.org,
"Eli Zaretskii" <eliz@gnu.org>,
aqua0210@foxmail.com
Subject: bug#72176: 30.0.60; icomplete-vertical-mode failed to work with Error
Date: Sun, 21 Jul 2024 17:42:24 -0400 [thread overview]
Message-ID: <jwvbk2q1lg9.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <m1frs4ko15.fsf@dazzs-mbp.home> (Eshel Yaron's message of "Sat, 20 Jul 2024 18:48:22 +0200")
> 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 :)
How do you dare to put in doubt the perfection of my code!
> 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
That's helpful. So the "main assumption" is valid.
Indeed in your recipe the problem is that the while loop you comment out
(which implements the shortcut based on the "second assumption") ends up
throwing away the chunk we need. This is by nature very hackish,
and there will still be cases where it back-fires. Maybe indeed we
should just get rid of this shortcut, and maybe the resulting
performance is good enough.
Otherwise, the patch below should fix this particular occurrence.
BTW, while there's no doubt that the behavior displayed in your recipe
is undesirable, I consider it technically as "suboptimal" rather
than incorrect: the displayed completions are too verbose and confusing
but using them still ends up selecting the right file.
[ Which is why I changed the comment to clarify we want "the largest"
QPOS: in your recipe we end up returning a valid QPOS but not the
largest one. ]
Stefan
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 9ad072daaf5..6fa04e9a062 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3556,7 +3556,7 @@ completion-file-name-table
(file-error nil))) ;PCM often calls with invalid directories.
(defun completion--sifn-requote (upos qstr)
- ;; We're looking for `qpos' such that:
+ ;; We're looking for (the largest) `qpos' such that:
;; (equal (substring (substitute-in-file-name qstr) 0 upos)
;; (substitute-in-file-name (substring qstr 0 qpos)))
;; Big problem here: we have to reverse engineer substitute-in-file-name to
@@ -3586,11 +3586,12 @@ completion--sifn-requote
;; Main assumption: nothing after qpos should affect the text before upos,
;; so we can work our way backward from the end of qstr, one character
;; at a time.
- ;; Second assumptions: If qpos is far from the end this can be a bit slow,
+ ;; Second assumption: 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
+ (not (string-match-p "/[/~]" qstr boundary))
(progn
(setq qprefix (substring qstr 0 boundary))
(string-prefix-p uprefix
next prev parent reply other threads:[~2024-07-21 21:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 12:13 bug#72176: 30.0.60; icomplete-vertical-mode failed to work with Error Eason Huang
2024-07-18 12:41 ` Eli Zaretskii
2024-07-18 12:49 ` Visuwesh
2024-07-18 14:34 ` Robert Pluim
2024-07-18 15:34 ` Eli Zaretskii
2024-07-19 7:15 ` Robert Pluim
2024-07-20 6:05 ` Eli Zaretskii
2024-07-20 9:09 ` João Távora
2024-07-20 10:15 ` Eli Zaretskii
2024-07-20 16:48 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-21 2:27 ` Dmitry Gutov
2024-07-21 21:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-07-25 7:31 ` Eli Zaretskii
2024-07-25 12:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-20 10:07 ` Eason Huang
2024-07-20 10:43 ` Eli Zaretskii
2024-07-18 13:11 ` Arash Esbati
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvbk2q1lg9.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=72176@debbugs.gnu.org \
--cc=aqua0210@foxmail.com \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=joaotavora@gmail.com \
--cc=me@eshelyaron.com \
--cc=monnier@iro.umontreal.ca \
--cc=rpluim@gmail.com \
--cc=visuweshm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).