bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[João Távora]

Hello,

Originally reported by Dmitry Gutov <dmitry@gutov.dev> over
at bug#62029:

> It's trivially reproduced even with 'emacs -Q': just add somewhere
> inside an Elisp buffer:

>   (remove-hook asd)

> when flymake-mode is enabled and eldoc-documentation-strategy is
> 'eldoc-documentation-compose, and eldoc-echo-area-use-multiline-p is
> not 1, and move around 'asd' with C-f and C-b.

I've confirmed this in a graphical Emacs frame.  In a TTY frame, it's
harder or impossible to spot.  

Traced the problem down to a misimplementation of the
'eldoc-documentation-compose' strategy, which leads to potentially one
eldoc-message call to be issued for each member of
'eldoc-documentation-functions'.  In fact, with this particular
strategy, the intention at most one such call should occur (after all
the documentation items of different backends have been collected).

It's reasonably easy to fix, and I've been running the patch after my
sig all day with no problems either in Elisp or other modes.  The
"blinking" observed before is gone.

I'll push it to master soon, but leave this issue open for comments
and/or feedback a little longer.

João

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index 1eb0d38c5ce..55fb518f990 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -681,29 +681,34 @@ eldoc-documentation-default
                     (lambda (f)
                       (funcall f (eldoc--make-callback :eager f)))))
 
-(defun eldoc--documentation-compose-1 (eagerlyp)
-  "Helper function for composing multiple doc strings.
-If EAGERLYP is non-nil show documentation as soon as possible,
-else wait for all doc strings."
-  (run-hook-wrapped 'eldoc-documentation-functions
-                    (lambda (f)
-                      (let* ((callback (eldoc--make-callback
-                                        (if eagerlyp :eager :patient)
-                                        f))
-                             (str (funcall f callback)))
-                        (if (or (null str) (stringp str)) (funcall callback str))
-                        nil)))
-  t)
-
 (defun eldoc-documentation-compose ()
   "Show multiple documentation strings together after waiting for all of them.
 This is meant to be used as a value for `eldoc-documentation-strategy'."
-  (eldoc--documentation-compose-1 nil))
+  (let (fns-and-callbacks)
+    ;; Make all the callbacks, this sets up state inside
+    ;; `eldoc--invoke-strategy' to know how many to wait for before
+    ;; displaying (bug#xxxxx)
+    (run-hook-wrapped 'eldoc-documentation-functions
+                      (lambda (f)
+                        (push (cons f (eldoc--make-callback :patient f))
+                              fns-and-callbacks)
+                        nil))
+    ;; Now call them.  The last one will trigger the display.
+    (cl-loop for (f . callback) in fns-and-callbacks
+             for str = (funcall f callback)
+             when (or (null str) (stringp str)) do (funcall callback str)))
+  t)
 
 (defun eldoc-documentation-compose-eagerly ()
   "Show multiple documentation strings one by one as soon as possible.
 This is meant to be used as a value for `eldoc-documentation-strategy'."
-  (eldoc--documentation-compose-1 t))
+  (run-hook-wrapped 'eldoc-documentation-functions
+                    (lambda (f)
+                      (let* ((callback (eldoc--make-callback :eager f))
+                             (str (funcall f callback)))
+                        (if (or (null str) (stringp str)) (funcall callback str))
+                        nil)))
+  t)
 
 (defun eldoc-documentation-enthusiast ()
   "Show most important documentation string produced so far.

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[Dmitry Gutov]

On 13/04/2023 17:47, João Távora wrote:
> Hello,
> 
> Originally reported by Dmitry Gutov <dmitry@gutov.dev> over
> at bug#62029:
> 
>> It's trivially reproduced even with 'emacs -Q': just add somewhere
>> inside an Elisp buffer:
> 
>>    (remove-hook asd)
> 
>> when flymake-mode is enabled and eldoc-documentation-strategy is
>> 'eldoc-documentation-compose, and eldoc-echo-area-use-multiline-p is
>> not 1, and move around 'asd' with C-f and C-b.
> 
> I've confirmed this in a graphical Emacs frame.  In a TTY frame, it's
> harder or impossible to spot.
> 
> Traced the problem down to a misimplementation of the
> 'eldoc-documentation-compose' strategy, which leads to potentially one
> eldoc-message call to be issued for each member of
> 'eldoc-documentation-functions'.  In fact, with this particular
> strategy, the intention at most one such call should occur (after all
> the documentation items of different backends have been collected).
> 
> It's reasonably easy to fix, and I've been running the patch after my
> sig all day with no problems either in Elisp or other modes.  The
> "blinking" observed before is gone.
> 
> I'll push it to master soon, but leave this issue open for comments
> and/or feedback a little longer.

Thank you, it does seems to fix the issue with C-f/C-b in elisp-mode, in 
the described situation.

I still see the problem with window jumping and blinking when typing 
with company-mode enabled, though. You say: "I do use company and 
multi-line echo areas liberally". Do you have some extra configuration 
for company-frontends?

Here's a screencast that demonstrates the problem:

https://a.uguu.se/csTMrzxc.webm

One way to fix that is

   (delq 'company-echo-metadata-frontend company-frontends)

but I wonder whether some better solution exists.

OTOH, Eglot implements the attribute which this frontend plugs into via 
:company-docsig, and it seems like both with LSP servers that I just 
tried it returns nil. If the feature is generally unused, I could 
understand if Eglot users all disable this frontend anyway.

It is handy to have in emacs-lisp-mode, though. At least when there is 
no documentation popup floating nearby.

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[João Távora]

Dmitry Gutov <dmitry@gutov.dev> writes:

> I still see the problem with window jumping and blinking when typing
> with company-mode enabled, though. You say: "I do use company and
> multi-line echo areas liberally". Do you have some extra configuration
> for company-frontends?

Not that I know of.  I just use a TTY frame.  I don't see it.  The echo
area is frequently empty for me when selecting Eglot completions (in
clangd, the server I most use nowadays).

> Here's a screencast that demonstrates the problem:
> https://a.uguu.se/csTMrzxc.webm

Ugh, that indeed looks awful.  We must fix it.

> One way to fix that is
>   (push 'company-echo-metadata-frontend company-frontends)
> but I wonder whether some better solution exists.

I hope so.

> OTOH, Eglot implements the attribute which this frontend plugs into
> via :company-docsig, and it seems like both with LSP servers that I
> just tried it returns nil. If the feature is generally unused, I could
> understand if Eglot users all disable this frontend anyway.

I don't think that's the best solution.  Though you're right that only
one server, pyright, uses this (it's some user's hack in eglot.el I let
through: I don't even know what it does, i think it tells)

But, perhaps to ask the obvious, why can't Company just detect when nil
is passed to it via :company-docsig and not do any echoing in that
situation?  Isn't it Company doing the clearing we want to avoid?

Another option is just to temporarily disable eldoc during the duration
of the Company completion session.  

I think Company could/should do both of these things, but I haven't
studied the problem so I might be missing something.

João

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[Dmitry Gutov]

On 14/04/2023 02:23, João Távora wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> I still see the problem with window jumping and blinking when typing
>> with company-mode enabled, though. You say: "I do use company and
>> multi-line echo areas liberally". Do you have some extra configuration
>> for company-frontends?
> 
> Not that I know of.  I just use a TTY frame.  I don't see it.  The echo
> area is frequently empty for me when selecting Eglot completions (in
> clangd, the server I most use nowadays).
> 
>> Here's a screencast that demonstrates the problem:
>> https://a.uguu.se/csTMrzxc.webm
> 
> Ugh, that indeed looks awful.  We must fix it.
> 
>> One way to fix that is
>>    (push 'company-echo-metadata-frontend company-frontends)

Sorry, that was supposed to be (delete ...). The one above restores the 
configuration -- I needed it for a repeat comparison.

>> but I wonder whether some better solution exists.
> 
> I hope so.
> 
>> OTOH, Eglot implements the attribute which this frontend plugs into
>> via :company-docsig, and it seems like both with LSP servers that I
>> just tried it returns nil. If the feature is generally unused, I could
>> understand if Eglot users all disable this frontend anyway.
> 
> I don't think that's the best solution.  Though you're right that only
> one server, pyright, uses this (it's some user's hack in eglot.el I let
> through: I don't even know what it does, i think it tells)

Maybe other servers have different bits of info that could be used for this?

> But, perhaps to ask the obvious, why can't Company just detect when nil
> is passed to it via :company-docsig and not do any echoing in that
> situation?  Isn't it Company doing the clearing we want to avoid?

I think it does need to clear the echo area when it was previously 
echoed to by the same backend (showing meta from a different 
completion). E.g. after the user just presses C-n with completion popup 
already visible. So the idea to "just not do any echoes" would require 
some bookkeeping about where the current message came from, compare the 
current message contents, and possibly still fail sometimes where the 
exact same message came from a different source. The last one is 
unlikely, though.

> Another option is just to temporarily disable eldoc during the duration
> of the Company completion session.

Right.

And yet another solution would be to detect that Eldoc will be used, and 
try to plug into its documentation functions to display the meta thingy 
alongside the other info.

That's at least 3 potential solutions now.

> I think Company could/should do both of these things, but I haven't
> studied the problem so I might be missing something.

I've looked into that issue in the past, but haven't picked one yet.

Related:
https://github.com/company-mode/company-mode/issues/797
https://github.com/company-mode/company-mode/issues/588
https://github.com/company-mode/company-mode/issues/796

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[João Távora]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 14/04/2023 02:23, João Távora wrote:
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>> 
>>> I still see the problem with window jumping and blinking when typing
>>> with company-mode enabled, though. You say: "I do use company and
>>> multi-line echo areas liberally". Do you have some extra configuration
>>> for company-frontends?
>> Not that I know of.  I just use a TTY frame.  I don't see it.  The
>> echo
>> area is frequently empty for me when selecting Eglot completions (in
>> clangd, the server I most use nowadays).
>> 
>>> Here's a screencast that demonstrates the problem:
>>> https://a.uguu.se/csTMrzxc.webm
>> Ugh, that indeed looks awful.  We must fix it.
>> 
>>> One way to fix that is
>>>    (push 'company-echo-metadata-frontend company-frontends)
>
> Sorry, that was supposed to be (delete ...). The one above restores
> the configuration -- I needed it for a repeat comparison.

Ahaha :-) No, no, I did exactly the same and misquoted you.  I put the
push there to restore it, with a quick C-x C-e.  You did send the delq.

>>> but I wonder whether some better solution exists.
>> I hope so.
>> 
>>> OTOH, Eglot implements the attribute which this frontend plugs into
>>> via :company-docsig, and it seems like both with LSP servers that I
>>> just tried it returns nil. If the feature is generally unused, I could
>>> understand if Eglot users all disable this frontend anyway.
>> I don't think that's the best solution.  Though you're right that
>> only
>> one server, pyright, uses this (it's some user's hack in eglot.el I let
>> through: I don't even know what it does, i think it tells)
>
> Maybe other servers have different bits of info that could be used for
> this?

Probably.  Just looked at the spec, there's are two different "detail"
fields (though it's not clear which one to pick or where exactly to send
them).  See
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_completion
if you're interested, and search down for "detail".  But are you saying
that if that :company-docsig is taken out completely, the problem will
not happen?  Maybe I can put it in only for the pyright server.

>> But, perhaps to ask the obvious, why can't Company just detect when nil
>> is passed to it via :company-docsig and not do any echoing in that
>> situation?  Isn't it Company doing the clearing we want to avoid?
>
> I think it does need to clear the echo area when it was previously
> echoed to by the same backend (showing meta from a different
> completion). E.g. after the user just presses C-n with completion
> popup already visible. So the idea to "just not do any echoes" would
> require some bookkeeping about where the current message came from,
> compare the current message contents, and possibly still fail
> sometimes where the exact same message came from a different
> source. The last one is unlikely, though.

I see.  Eglot only uses one Company source, company-capf, if that helps.

>> Another option is just to temporarily disable eldoc during the duration
>> of the Company completion session.
>
> Right.
>
> And yet another solution would be to detect that Eldoc will be used,
> and try to plug into its documentation functions to display the meta
> thingy alongside the other info.
>
> That's at least 3 potential solutions now.

I think you should do the "bookkeeping" one, at least a very simple
version.  Just record in your concept of a "company session" if there
was ever a non-nil :company-docsig sent from anywhere that required
echoing.  Until there is, never clear on nil :company-docsig.
Eventually, if there is something to echo, tough luck: display it and
proceed as currently, clearing always on nil, risking flickering.
Suspect this should fix 95% of the cases, certainly Eglot usages.

João

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[Dmitry Gutov]

On 14/04/2023 03:16, João Távora wrote:

>>>> Here's a screencast that demonstrates the problem:
>>>> https://a.uguu.se/csTMrzxc.webm
>>> Ugh, that indeed looks awful.  We must fix it.
>>>
>>>> One way to fix that is
>>>>     (push 'company-echo-metadata-frontend company-frontends)
>>
>> Sorry, that was supposed to be (delete ...). The one above restores
>> the configuration -- I needed it for a repeat comparison.
> 
> Ahaha :-) No, no, I did exactly the same and misquoted you.  I put the
> push there to restore it, with a quick C-x C-e.  You did send the delq.

Oh. :-)

>>>> but I wonder whether some better solution exists.
>>> I hope so.
>>>
>>>> OTOH, Eglot implements the attribute which this frontend plugs into
>>>> via :company-docsig, and it seems like both with LSP servers that I
>>>> just tried it returns nil. If the feature is generally unused, I could
>>>> understand if Eglot users all disable this frontend anyway.
>>> I don't think that's the best solution.  Though you're right that
>>> only
>>> one server, pyright, uses this (it's some user's hack in eglot.el I let
>>> through: I don't even know what it does, i think it tells)
>>
>> Maybe other servers have different bits of info that could be used for
>> this?
> 
> Probably.  Just looked at the spec, there's are two different "detail"
> fields (though it's not clear which one to pick or where exactly to send
> them).  See
> https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_completion
> if you're interested, and search down for "detail".

"Detail" does sound relevant. But it depends on what info the servers 
actually provide in it.

> But are you saying
> that if that :company-docsig is taken out completely, the problem will
> not happen?  Maybe I can put it in only for the pyright server.

Not exactly: the backend interface doesn't differentiate between a not 
implemented action and action returning nil. Not for 'meta' anyway.

>>> But, perhaps to ask the obvious, why can't Company just detect when nil
>>> is passed to it via :company-docsig and not do any echoing in that
>>> situation?  Isn't it Company doing the clearing we want to avoid?
>>
>> I think it does need to clear the echo area when it was previously
>> echoed to by the same backend (showing meta from a different
>> completion). E.g. after the user just presses C-n with completion
>> popup already visible. So the idea to "just not do any echoes" would
>> require some bookkeeping about where the current message came from,
>> compare the current message contents, and possibly still fail
>> sometimes where the exact same message came from a different
>> source. The last one is unlikely, though.
> 
> I see.  Eglot only uses one Company source, company-capf, if that helps.

Alas no.

>>> Another option is just to temporarily disable eldoc during the duration
>>> of the Company completion session.
>>
>> Right.
>>
>> And yet another solution would be to detect that Eldoc will be used,
>> and try to plug into its documentation functions to display the meta
>> thingy alongside the other info.
>>
>> That's at least 3 potential solutions now.
> 
> I think you should do the "bookkeeping" one, at least a very simple
> version.  Just record in your concept of a "company session" if there
> was ever a non-nil :company-docsig sent from anywhere that required
> echoing.  Until there is, never clear on nil :company-docsig.
> Eventually, if there is something to echo, tough luck: display it and
> proceed as currently, clearing always on nil, risking flickering.
> Suspect this should fix 95% of the cases, certainly Eglot usages.

Yeah, that should be the most conservative solution. Maybe I'll start 
with it.

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[Dmitry Gutov]

On 14/04/2023 03:22, Dmitry Gutov wrote:
>>>> Another option is just to temporarily disable eldoc during the duration
>>>> of the Company completion session.
>>>
>>> Right.
>>>
>>> And yet another solution would be to detect that Eldoc will be used,
>>> and try to plug into its documentation functions to display the meta
>>> thingy alongside the other info.
>>>
>>> That's at least 3 potential solutions now.
>>
>> I think you should do the "bookkeeping" one, at least a very simple
>> version.  Just record in your concept of a "company session" if there
>> was ever a non-nil :company-docsig sent from anywhere that required
>> echoing.  Until there is, never clear on nil :company-docsig.
>> Eventually, if there is something to echo, tough luck: display it and
>> proceed as currently, clearing always on nil, risking flickering.
>> Suspect this should fix 95% of the cases, certainly Eglot usages.
> 
> Yeah, that should be the most conservative solution. Maybe I'll start 
> with it.

I've pushed a halfway-there solution which still seems to satisfy both 
main scenarios (exemplified by Elisp and Eglot), so that seems addressed.

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[Dmitry Gutov]

On 13/04/2023 17:47, João Távora wrote:
> I'll push it to master soon, but leave this issue open for comments
> and/or feedback a little longer.

Perhaps we want to backport it to emacs-29 as well? It *is* a bug, after 
all.

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[João Távora]

On Fri, Apr 14, 2023 at 7:03 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 13/04/2023 17:47, João Távora wrote:
> > I'll push it to master soon, but leave this issue open for comments
> > and/or feedback a little longer.
>
> Perhaps we want to backport it to emacs-29 as well? It *is* a bug, after
> all.

Perhaps.  Yes it's a bug.  But at this point, I think that's for Eli
to decide (i.e. I don't exactly what the policy is now vs two/three
weeks ago).

João

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[Eli Zaretskii]

> Cc: 62816@debbugs.gnu.org
> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 14 Apr 2023 19:09:20 +0100
> 
> On Fri, Apr 14, 2023 at 7:03 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> >
> > On 13/04/2023 17:47, João Távora wrote:
> > > I'll push it to master soon, but leave this issue open for comments
> > > and/or feedback a little longer.
> >
> > Perhaps we want to backport it to emacs-29 as well? It *is* a bug, after
> > all.
> 
> Perhaps.  Yes it's a bug.  But at this point, I think that's for Eli
> to decide (i.e. I don't exactly what the policy is now vs two/three
> weeks ago).

It depends on how bad is the bug, whether it's a regression since
Emacs 28, and how safe is the fix.  In general, bugs should be fixed
on the release branch, unless the risk associated with the fix is too
high.

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[João Távora]

On Fri, Apr 14, 2023 at 7:53 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: 62816@debbugs.gnu.org
> > From: João Távora <joaotavora@gmail.com>
> > Date: Fri, 14 Apr 2023 19:09:20 +0100
> >
> > On Fri, Apr 14, 2023 at 7:03 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> > >
> > > On 13/04/2023 17:47, João Távora wrote:
> > > > I'll push it to master soon, but leave this issue open for comments
> > > > and/or feedback a little longer.
> > >
> > > Perhaps we want to backport it to emacs-29 as well? It *is* a bug, after
> > > all.
> >
> > Perhaps.  Yes it's a bug.  But at this point, I think that's for Eli
> > to decide (i.e. I don't exactly what the policy is now vs two/three
> > weeks ago).
>
> It depends on how bad is the bug, whether it's a regression since
> Emacs 28, and how safe is the fix.  In general, bugs should be fixed
> on the release branch, unless the risk associated with the fix is too
> high.

Right, exactly.  We were just talking about that.  This is not a
regression from Emacs 28 (I'm 99% sure).  It was already there.
But the bug is so-so-serious (somewhat annoying flickering, though
not in TTY frames).  The fix is simple enough (IMHO, of course,
because I wrote the code ... and the bug).

Do note, also, Eli, that ElDoc is a :core package.  So, if we
don't backport, people really really annoyed with this bug (
which manifests itself with Eglot primarily, though it could
manifest with other packages) can get the bugfix if they simply
upgrade ElDoc OR Eglot.  Whether it's easy or not to do that
is a matter for bug#62720.  Of course they might also get
_other_ bugs and new features, etc if they upgrade.

So maybe that weighs on your decision.  You can check out the fix
in 83b5e9cd24ddcbb04dbd5db9a07248ff7fa301ab.  If you don't say
anything I will backport in a few days.

João

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 14 Apr 2023 20:58:16 +0100
> Cc: dmitry@gutov.dev, 62816@debbugs.gnu.org
> 
> > > > Perhaps we want to backport it to emacs-29 as well? It *is* a bug, after
> > > > all.
> > >
> > > Perhaps.  Yes it's a bug.  But at this point, I think that's for Eli
> > > to decide (i.e. I don't exactly what the policy is now vs two/three
> > > weeks ago).
> >
> > It depends on how bad is the bug, whether it's a regression since
> > Emacs 28, and how safe is the fix.  In general, bugs should be fixed
> > on the release branch, unless the risk associated with the fix is too
> > high.
> 
> Right, exactly.  We were just talking about that.  This is not a
> regression from Emacs 28 (I'm 99% sure).  It was already there.
> But the bug is so-so-serious (somewhat annoying flickering, though
> not in TTY frames).  The fix is simple enough (IMHO, of course,
> because I wrote the code ... and the bug).

What is the bug, exactly?  Is it just that the mini-window gets
resized back and forth in some scenario?  Or is it something else?

> Do note, also, Eli, that ElDoc is a :core package.  So, if we
> don't backport, people really really annoyed with this bug (
> which manifests itself with Eglot primarily, though it could
> manifest with other packages) can get the bugfix if they simply
> upgrade ElDoc OR Eglot.  Whether it's easy or not to do that
> is a matter for bug#62720.  Of course they might also get
> _other_ bugs and new features, etc if they upgrade.

Right, so I don't think this aspect is very relevant to the decision
whether to backport the fix.

> So maybe that weighs on your decision.  You can check out the fix
> in 83b5e9cd24ddcbb04dbd5db9a07248ff7fa301ab.

Sounds scary.  I'd prefer to leave it on master at this time.  Unless
the bug it fixes is more than just resizing of the mini-window.

Thanks.

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[João Távora]

On Sat, Apr 15, 2023 at 10:13 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > So maybe that weighs on your decision.  You can check out the fix
> > in 83b5e9cd24ddcbb04dbd5db9a07248ff7fa301ab.
>
> Sounds scary.  I'd prefer to leave it on master at this time.  Unless
> the bug it fixes is more than just resizing of the mini-window.

OK.  That was my initial assessment too (though I wouldn't call it
scary).

So I guess I'm closing the bug, as there's nothing more to do.
João

bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used

[Dmitry Gutov]

On 15/04/2023 12:13, Eli Zaretskii wrote:
>> Right, exactly.  We were just talking about that.  This is not a
>> regression from Emacs 28 (I'm 99% sure).  It was already there.
>> But the bug is so-so-serious (somewhat annoying flickering, though
>> not in TTY frames).  The fix is simple enough (IMHO, of course,
>> because I wrote the code ... and the bug).
> What is the bug, exactly?  Is it just that the mini-window gets
> resized back and forth in some scenario?  Or is it something else?

Resized back and forth, and "blinks" with blank content after every user 
keypress. Which makes it quite annoying to use 
eldoc-documentation-compose in GUI Emacs.

The effect is only visual, though.