* bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words
@ 2019-11-01 21:40 Kévin Le Gouguec
2019-11-01 23:28 ` João Távora
0 siblings, 1 reply; 8+ messages in thread
From: Kévin Le Gouguec @ 2019-11-01 21:40 UTC (permalink / raw)
To: 38024; +Cc: João Távora
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
Hello,
tl;dr unless I'm mistaken, sometimes `while-no-input' returns t despite
no input having arrived; this prevents `icomplete-exhibit' from
displaying completion candidates.
In more details:
This is a bit of a heisenbug; hopefully someone out there will know what
knobs to tweak to find more information about this.
From emacs -Q:
M-x icomplete-mode RET
;; Find a way to set `default-directory' to some long-ish path,
;; e.g. with:
M-x find-library RET icomplete RET
C-x C-f
;; icomplete should show a bunch of completions.
M-DEL
M-DEL
…
After each `backward-kill-word', icomplete usually displays new
completion candidates with no further user input; sometimes however, no
candidates show up until the user does something (e.g. press TAB or
start typing).
Commit 5860fd3 (Make icomplete-exhibit actually work when navigating up
directories) tried to fix this, but AFAICT it merely reduces the odds of
the bug happening: I can still reproduce it, although less often. Also,
this new call to `redisplay' causes some noticeable flickering when
typing characters: the completions blink in and out as I fill in the
prompt.
I've tinkered with icomplete.el (commenting out the call to `redisplay'
since it makes the bug harder to trigger); the closest I got to
pin-pointing the cause for this issue was while goofing around in
`icomplete-exhibit', specifically with the `while-no-input' part:
(let* (…
(text (while-no-input
(icomplete-completions
…)))
…)
;; Do nothing if while-no-input was aborted.
(when (stringp text)
update overlay…))
I replaced (when (stringp text) …) with (if (stringp text) (progn …)
(message "text is %s" text)): it seems that text is t when icomplete
fails to show updated candidates, which according to `while-no-input'
means that some input arrived…
However, when I tried to debug `while-no-input', I got stumped: I tried
to do some more printf-debugging[1], but all I observe is that
sometimes, the code seems to be interrupted between
(let ((throw-on-input ',catch-sym)
val)
and
(setq val (or (input-pending-p)
(progn ,@body)))
I tried to find where exactly the code gets interrupted, but I could not
get a consistent answer; sometimes it seems to be before executing body,
sometimes it seems to be somewhere inside `icomplete-completions'…
What would be the best way to investigate this further?
Thank you for your time.
[1] With this patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: icomplete-debug.patch --]
[-- Type: text/x-diff, Size: 3410 bytes --]
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 02eae55a19..31023d5644 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -399,8 +399,6 @@ icomplete-exhibit
See `icomplete-mode' and `minibuffer-setup-hook'."
(when (and icomplete-mode
(icomplete-simple-completing-p)) ;Shouldn't be necessary.
- (redisplay) ; FIXME: why is this sometimes needed when moving
- ; up dirs in a file-finding table?
(save-excursion
(goto-char (point-max))
; Insert the match-status information:
@@ -430,13 +428,15 @@ icomplete-exhibit
(buffer-undo-list t)
deactivate-mark)
;; Do nothing if while-no-input was aborted.
- (when (stringp text)
- (move-overlay icomplete-overlay (point) (point) (current-buffer))
- ;; The current C cursor code doesn't know to use the overlay's
- ;; marker's stickiness to figure out whether to place the cursor
- ;; before or after the string, so let's spoon-feed it the pos.
- (put-text-property 0 1 'cursor t text)
- (overlay-put icomplete-overlay 'after-string text)))))))
+ (if (stringp text)
+ (progn
+ (move-overlay icomplete-overlay (point) (point) (current-buffer))
+ ;; The current C cursor code doesn't know to use the overlay's
+ ;; marker's stickiness to figure out whether to place the cursor
+ ;; before or after the string, so let's spoon-feed it the pos.
+ (put-text-property 0 1 'cursor t text)
+ (overlay-put icomplete-overlay 'after-string text))
+ (message "text is %s" text)))))))
;;;_ > icomplete-completions (name candidates predicate require-match)
(defun icomplete-completions (name candidates predicate require-match)
diff --git a/lisp/subr.el b/lisp/subr.el
index b408ef0931..3610fe30f2 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3727,11 +3727,14 @@ while-no-input
(declare (debug t) (indent 0))
(let ((catch-sym (make-symbol "input")))
`(with-local-quit
+ (message "after with-local-quit")
(catch ',catch-sym
(let ((throw-on-input ',catch-sym)
val)
+ (message "after catch and let")
(setq val (or (input-pending-p)
(progn ,@body)))
+ (message "after setq val")
(cond
;; When input arrives while throw-on-input is non-nil,
;; kbd_buffer_store_buffered_event sets quit-flag to the
@@ -3746,13 +3749,17 @@ while-no-input
;; such as discarding input etc. We return t in that case
;; because input did arrive during execution of BODY.
((eq quit-flag throw-on-input)
+ (message "cond: got input")
(setq quit-flag nil)
t)
;; This is for when the user actually QUITs during
;; execution of BODY.
(quit-flag
+ (message "cond: got quit-flag %s" quit-flag)
nil)
- (t val)))))))
+ (t
+ (message "cond: return val")
+ val)))))))
(defmacro condition-case-unless-debug (var bodyform &rest handlers)
"Like `condition-case' except that it does not prevent debugging.
[-- Attachment #3: Type: text/plain, Size: 1056 bytes --]
When the bug happens, I get the following messages:
after with-local-quit
after catch and let
text is t
PS: It just occured to me that I should search debbugs for
"while-no-input" in addition to "icomplete". I just did that;
bug#15042 looks like it could maybe be related?
In GNU Emacs 27.0.50 (build 6, i686-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
of 2019-10-21 built on little-buster
Repository revision: 61fb5214816ef3d57e676d900e499ffcd079a1f9
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)
Configured using:
'configure --with-xwidgets --with-cairo'
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 XWIDGETS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words
2019-11-01 21:40 bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words Kévin Le Gouguec
@ 2019-11-01 23:28 ` João Távora
2019-11-02 3:05 ` João Távora
0 siblings, 1 reply; 8+ messages in thread
From: João Távora @ 2019-11-01 23:28 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 38024, monnier
[-- Attachment #1: Type: text/plain, Size: 4376 bytes --]
Kevin, you're on the right track. The redisplay thing is not the right fix,
indeed. Stefan has a fix for this, which he sent me, but I can't find it
now.
Anyway, it has to do with avoiding the 'select' event in while-no-input.
In case you want to try that before Stefan drops by.
João
On Fri, Nov 1, 2019, 21:40 Kévin Le Gouguec <kevin.legouguec@gmail.com>
wrote:
> Hello,
>
> tl;dr unless I'm mistaken, sometimes `while-no-input' returns t despite
> no input having arrived; this prevents `icomplete-exhibit' from
> displaying completion candidates.
>
> In more details:
>
> This is a bit of a heisenbug; hopefully someone out there will know what
> knobs to tweak to find more information about this.
>
> From emacs -Q:
>
> M-x icomplete-mode RET
> ;; Find a way to set `default-directory' to some long-ish path,
> ;; e.g. with:
> M-x find-library RET icomplete RET
> C-x C-f
> ;; icomplete should show a bunch of completions.
> M-DEL
> M-DEL
> …
>
> After each `backward-kill-word', icomplete usually displays new
> completion candidates with no further user input; sometimes however, no
> candidates show up until the user does something (e.g. press TAB or
> start typing).
>
> Commit 5860fd3 (Make icomplete-exhibit actually work when navigating up
> directories) tried to fix this, but AFAICT it merely reduces the odds of
> the bug happening: I can still reproduce it, although less often. Also,
> this new call to `redisplay' causes some noticeable flickering when
> typing characters: the completions blink in and out as I fill in the
> prompt.
>
> I've tinkered with icomplete.el (commenting out the call to `redisplay'
> since it makes the bug harder to trigger); the closest I got to
> pin-pointing the cause for this issue was while goofing around in
> `icomplete-exhibit', specifically with the `while-no-input' part:
>
> (let* (…
> (text (while-no-input
> (icomplete-completions
> …)))
> …)
> ;; Do nothing if while-no-input was aborted.
> (when (stringp text)
> update overlay…))
>
> I replaced (when (stringp text) …) with (if (stringp text) (progn …)
> (message "text is %s" text)): it seems that text is t when icomplete
> fails to show updated candidates, which according to `while-no-input'
> means that some input arrived…
>
> However, when I tried to debug `while-no-input', I got stumped: I tried
> to do some more printf-debugging[1], but all I observe is that
> sometimes, the code seems to be interrupted between
>
> (let ((throw-on-input ',catch-sym)
> val)
> and
> (setq val (or (input-pending-p)
> (progn ,@body)))
>
> I tried to find where exactly the code gets interrupted, but I could not
> get a consistent answer; sometimes it seems to be before executing body,
> sometimes it seems to be somewhere inside `icomplete-completions'…
>
> What would be the best way to investigate this further?
>
> Thank you for your time.
>
>
> [1] With this patch:
>
>
> When the bug happens, I get the following messages:
>
> after with-local-quit
> after catch and let
> text is t
>
>
> PS: It just occured to me that I should search debbugs for
> "while-no-input" in addition to "icomplete". I just did that;
> bug#15042 looks like it could maybe be related?
>
>
> In GNU Emacs 27.0.50 (build 6, i686-pc-linux-gnu, GTK+ Version 3.24.5,
> cairo version 1.16.0)
> of 2019-10-21 built on little-buster
> Repository revision: 61fb5214816ef3d57e676d900e499ffcd079a1f9
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
> System Description: Debian GNU/Linux 10 (buster)
>
> Configured using:
> 'configure --with-xwidgets --with-cairo'
>
> 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 XWIDGETS
> LIBSYSTEMD JSON PDUMPER LCMS2 GMP
>
> Important settings:
> value of $LANG: en_US.UTF-8
> locale-coding-system: utf-8-unix
>
[-- Attachment #2: Type: text/html, Size: 5290 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words
2019-11-01 23:28 ` João Távora
@ 2019-11-02 3:05 ` João Távora
2019-11-02 7:37 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: João Távora @ 2019-11-02 3:05 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 38024, Stefan Monnier
João Távora <joaotavora@gmail.com> writes:
> Kevin, you're on the right track. The redisplay thing is not the right
> fix, indeed. Stefan has a fix for this, which he sent me, but I can't
> find it now.
>
> Anyway, it has to do with avoiding the 'select' event in
> while-no-input.
Hi Kévin,
In the meantime, I found the patch and pushed it right away. It worked
better than the redisplay hack I had pushed before.
The commit you want to test with is
730e7da7ba6a4b545176ea246653928edb10cff4
Let me know how it works for you,
João
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words
2019-11-02 3:05 ` João Távora
@ 2019-11-02 7:37 ` Eli Zaretskii
2019-11-02 11:12 ` João Távora
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2019-11-02 7:37 UTC (permalink / raw)
To: João Távora; +Cc: 38024, monnier, kevin.legouguec
> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 02 Nov 2019 03:05:17 +0000
> Cc: 38024@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
>
> João Távora <joaotavora@gmail.com> writes:
>
> > Kevin, you're on the right track. The redisplay thing is not the right
> > fix, indeed. Stefan has a fix for this, which he sent me, but I can't
> > find it now.
> >
> > Anyway, it has to do with avoiding the 'select' event in
> > while-no-input.
>
> Hi Kévin,
>
> In the meantime, I found the patch and pushed it right away. It worked
> better than the redisplay hack I had pushed before.
>
> The commit you want to test with is
> 730e7da7ba6a4b545176ea246653928edb10cff4
The current master displays this warning when byte-compiling
icomplete.el:
ELC icomplete.elc
In end of data:
icomplete.el:669:1:Warning: the function `while-no-input-ignore-events' is not
known to be defined.
while-no-input-ignore-events is not a function, it's a variable.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words
2019-11-02 7:37 ` Eli Zaretskii
@ 2019-11-02 11:12 ` João Távora
2019-11-02 13:07 ` Eli Zaretskii
2021-04-05 20:59 ` Stefan Monnier
0 siblings, 2 replies; 8+ messages in thread
From: João Távora @ 2019-11-02 11:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38024, monnier, kevin.legouguec
Eli Zaretskii <eliz@gnu.org> writes:
> In end of data:
> icomplete.el:669:1:Warning: the function `while-no-input-ignore-events' is not
> known to be defined.
>
> while-no-input-ignore-events is not a function, it's a variable.
Sorry,
This was a merge blunder when reordering commits. The reference appears
again in the corrct variable form below. I've now fixed the problem in
6911ef3da69333cb7adc1a7fb0a0fc001220a0c4.
João
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words
2019-11-02 11:12 ` João Távora
@ 2019-11-02 13:07 ` Eli Zaretskii
2019-11-03 10:25 ` Kévin Le Gouguec
2021-04-05 20:59 ` Stefan Monnier
1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2019-11-02 13:07 UTC (permalink / raw)
To: João Távora; +Cc: 38024, monnier, kevin.legouguec
> From: João Távora <joaotavora@gmail.com>
> Cc: kevin.legouguec@gmail.com, 38024@debbugs.gnu.org,
> monnier@iro.umontreal.ca
> Date: Sat, 02 Nov 2019 11:12:07 +0000
>
> > while-no-input-ignore-events is not a function, it's a variable.
>
> Sorry,
>
> This was a merge blunder when reordering commits. The reference appears
> again in the corrct variable form below. I've now fixed the problem in
> 6911ef3da69333cb7adc1a7fb0a0fc001220a0c4.
Thanks, compiles cleanly now.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words
2019-11-02 13:07 ` Eli Zaretskii
@ 2019-11-03 10:25 ` Kévin Le Gouguec
0 siblings, 0 replies; 8+ messages in thread
From: Kévin Le Gouguec @ 2019-11-03 10:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38024-done, João Távora, monnier
Eli Zaretskii <eliz@gnu.org> writes:
> Thanks, compiles cleanly now.
And AFAICT, everything's fine now! (Completions show up no matter how
many M-DELs I hit; no more flickering when typing.)
Thank you all for working on this; closing (if I'm reading
admin/notes/bugtracker correctly).
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words
2019-11-02 11:12 ` João Távora
2019-11-02 13:07 ` Eli Zaretskii
@ 2021-04-05 20:59 ` Stefan Monnier
1 sibling, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2021-04-05 20:59 UTC (permalink / raw)
To: João Távora; +Cc: Daniel Mendler, 38024, kevin.legouguec
[ Resending, as usual, since the bug was archived. Sorry. ]
João Távora [2019-11-02 11:12:07] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> In end of data:
>> icomplete.el:669:1:Warning: the function `while-no-input-ignore-events' is not
>> known to be defined.
>> while-no-input-ignore-events is not a function, it's a variable.
> Sorry,
> This was a merge blunder when reordering commits. The reference appears
> again in the corrct variable form below. I've now fixed the problem in
> 6911ef3da69333cb7adc1a7fb0a0fc001220a0c4.
Hmm... so the patch installed was basically:
commit 88f193ed05649b8c622867b8b2623b8cb08fdc96
Author: João Távora <joaotavora@gmail.com>
Date: Sat Nov 2 02:29:56 2019 +0000
Improve fix for icomplete's backward-kill-word bug#38024
* lisp/icomplete.el (icomplete-exhibit): Use
while-no-input-ignore-events, not redisplay.
Co-authored-by: Stefan Monnier <j.schmoe@example.org>
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 02eae55a19..89318ca4c7 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -399,8 +399,6 @@ icomplete-exhibit
See `icomplete-mode' and `minibuffer-setup-hook'."
(when (and icomplete-mode
(icomplete-simple-completing-p)) ;Shouldn't be necessary.
- (redisplay) ; FIXME: why is this sometimes needed when moving
- ; up dirs in a file-finding table?
(save-excursion
(goto-char (point-max))
; Insert the match-status information:
@@ -420,6 +418,11 @@ icomplete-exhibit
;; embarking on computing completions:
(sit-for icomplete-compute-delay)))
(let* ((field-string (icomplete--field-string))
+ ;; Not sure why, but such requests seem to come
+ ;; every once in a while. It's not fully
+ ;; deterministic but `C-x C-f M-DEL M-DEL ...'
+ ;; seems to trigger it fairly often!
+ (while-no-input-ignore-events '(selection-request))
(text (while-no-input
(icomplete-completions
field-string
but I don't understand why that would help and/or be needed:
`selection-request` is (and has been for many years) in the default
value of `while-no-input-ignore-events` (as set in `subr.el`), so what
this patch ends up doing is forcing `while-no-input` to exit with value
t in more cases (i.e. whenever one of the events in (focus-in focus-out
help-echo iconify-frame make-frame-visible) comes in) rather than
the opposite.
What am I missing?
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-04-05 20:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-01 21:40 bug#38024: 27.0.50; icomplete sometimes fails to show completions after backward-killing words Kévin Le Gouguec
2019-11-01 23:28 ` João Távora
2019-11-02 3:05 ` João Távora
2019-11-02 7:37 ` Eli Zaretskii
2019-11-02 11:12 ` João Távora
2019-11-02 13:07 ` Eli Zaretskii
2019-11-03 10:25 ` Kévin Le Gouguec
2021-04-05 20:59 ` Stefan Monnier
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).