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: