bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41531: 28.0.50; proper Eldoc async support


From: Theodor Thornhill
Subject: 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@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@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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]