GNU bug report logs - #41531
27.0.91; Better handle asynchronous eldoc backends

Previous Next

Full log

Message #104 received at 41531 <at> debbugs.gnu.org (full text, mbox):

From: Theodor Thornhill <theothornhill <at> pm.me>
To: João Távora <joaotavora <at> gmail.com>,
 Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: mvoteiza <at> udel.edu, 41531 <at> debbugs.gnu.org,
 Fredrik Bergroth <fbergroth <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#41531: 28.0.50; proper Eldoc async support
Date: Fri, 05 Jun 2020 17:50:38 +0000

Hello!

Thanks for pinging me -

I tried it, and it looks pretty cool. However, I noticed a few bugs.

(When using both the new eldoc and eglot):

Bug 1:      
1. Open a file
2. Start eglot
3. Hover something with "C-h ."
4. Switch to the new window that popped up.
5. C-x k (kill buffer)
6. Repeat step 3.
7. "invalid buffer" and eldoc is dead. 
8. Starting and stopping eldoc doesn't work   

This seems to happen since it uses the new buffer and updates it. When that buffer is deleted, it gets confused.


Bug 2:
1. (setq eldoc-echo-area-use-multiline-p nil)
2. eglot spits the whole thing on one line. This looks a bit weird since it uses both the signature and the documentation.

This may not be a bug, but right now IMO it looks a bit strange.

Bug 3:
1. "M-:"
2. Type "("
3. Minibuffer shows: eldoc-error: (wrong number of arguments (0 . 0) 1)

I think the first bug is the most problematic one though :)

However, I've started to take a liking to the no options set, with this version. I think I like the "truncate, press M-x ..." message more than the previous one.

All the best,

Theodor

João Távora <joaotavora <at> gmail.com> writes:

> [ Theodor and Fredrik, adding you since you were also interested in this
> Eglot/Eldoc matter.  You can review the messages in the bug list if
> you're interested:  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41531]
>
> Andrii Kolomoiets <andreyk.mad <at> gmail.com> writes:
>
>> I was planning to remove the eglot-put-doc-in-help-buffer variable in
>> the near future PR as well as the use of the eglot--message function for
>> the documentation display ;-)
>
> I'm guess I'm happy to have shot these plans into the depths of the
> ocean ;-)
>
>> However, after briefly using new Eldoc and Eglot I found some issues
>> that, I hope, we can fix:
>>
>> 1. Display only first line of the hover info.  Again :-)
>
> You should be able to do this with either
>
>    (setq eldoc-echo-area-use-multiline-p 1)
>
> or
>
>    (setq eldoc-echo-area-use-multiline-p nil)
>
> Did you try this? If so, what exactly didn't work for you when you did?
> I'm sorry if you've already given me this information in the multiple
> PR's you opened about this, but let's have it again.
>
>> 2. The hover info is sometimes displayed right before the signature info
>> making the echo area to "blink".  I suppose this must be fixed on Eglot
>> side by not requesting both the hover and the signature infos at the
>> same time.
>
> Not something to be fixed in Eglot, definitely, it's not its fault or
> responsibility: it just reports whatever it has.  I've fixed this in
> Eldoc, in the last commit.  It only affected the "eager" strategy (which
> should really be called the "enthusiast" strategy).  I'll post a commit
> soon using better names for strategies, I'm thinking:
>
> eldoc-documentation-function  -> eldoc-strategy         (with obsolete alias)
> eldoc-documentation-functions -> eldoc-functions        (maybe)
>
> eldoc-documentation-default  -> eldoc-patient
> eldoc-documentation-compose  -> eldoc-compose-patiently
> eldoc-documentation-eager    -> eldoc-enthusiast        (Eglot uses this)
>   <doesn't exist yet>        -> eldoc-compose-eagerly   (Stefan mentioned this)
>
>> 3. That IMO useless "...truncated, see *help* buffer" message is moved
>> to Eldoc.  Do we really need to show this message every time?
>
> I see.  Maybe not _every time_ but at least _once_, I'd say.  Once per
> Eldoc session (but what is an Eldoc session)?  Once per x truncated
> messages?  Customization variable? (I hate those, but maybe).
>
> Or maybe never show it?
>
>> That one last line can be used to show additional documentation.
>> Hadn't a chance to take a closer look at the code, so reporting those
>> issues is the most I can do for now.
>
> Yes, and that's fine for now, though a second pair of eyes in the code
> is certainly appreciated too.
>
> João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.