Hover vs. diagnostics (C-h .)

[nemethf]

Commit a0249c8 remapped display-local-help to eglot-help-at-point. I used C-h . to show diagnostics errors at point. Now if there are documentation and diagnostics at point, C-h . shows the former. Is there a keybinding to show the latter? If not, would it be possible to prioritize the diagnostics info and only show the documentation when, for example, C-h . is invoked with a prefix argument?

Thanks.

[joaotavora]

On Mon, May 4, 2020, 07:08 Felicián Németh ***@***.***> wrote: possible to prioritize the diagnostics info and only show the documentation when, for example, C-h . is invoked with a prefix argument?

Maybe the priorities could be inverted (diags before docs). Or show both in the help buffer. Or give up on this idea entirely, since keybindings isn't usually Eglot's business. João João

[nemethf]

Maybe the priorities could be inverted (diags before docs). Or show both in the help buffer. Or give up on this idea entirely, since keybindings isn't usually Eglot's business. João João

Theoretically there can be other sources producing local help besides Eglot/Flymake, so the first two alternatives are tricky to implement. At least, I don't know how to do it cleanly. The easiest would be to remove the keybinding, but a convenient combination of the diagnostics and the documentation does sound appealing.

[joaotavora]

Theoretically there can be other sources producing local help besides Eglot/Flymake,

That's why we fetch them with display-local-help or help-at-pt-kbd-string, so that's not a problem.

[nemethf]

Following your suggestion I've created a pull request for this.

However, if there are no diags, we might get something like this as an eldoc message:
(...truncated. Full help is in `*eglot-help for sys*'), which is OK, but instead of "full help is in ..." we could have written "Press C-h . for more.". With this PR, we cannot. I think that's probably not a big deal, but a missed opportunity.

[dandavison]

I'm also in favour of doing further work in this area. I don't mind what decisions are taken regarding keybindings, but how about the following approach:

• eglot contains code to construct a single buffer which can display information about the code-at-point from a variety of sources, including documentation, and compiler errors.
• users can configure which sources they wish to be included in that buffer.

In case it's helpful, here (from #481) are some screenshots of displaying compiler errors along with documentation:

Before	After

[dgutov]

For eglot-help-at-point, I like C-c C-d, SLIME-style.

[joaotavora]

Dmitry Gutov <notifications@github.com> writes:

For eglot-help-at-point, I like C-c C-d, SLIME-style.

As far as I know, C-c C-d is a prefix to lots of stuff in SLIME. Did you mean? C-c C-d d slime-describe-symbol Anyway, that doesn't describe the compilation error at point, if there is one.

[dgutov]

Did you mean?

I suppose. If Eglot is going to have multiple commands, to show docs for different "things" at point. But it probably won't.

Anyway, that doesn't describe the compilation error at point, if there is one.

Indeed. And I'd rather not mix these things.

[joaotavora]

Indeed. And I'd rather not mix these things.

Well, it seems to be the opinion of some actual users of Eglot (including myself) that there should be some tool to display information available in a given point context, which would include diagnostics and summarized documentation. That can be done either via eldoc or via help-at-point.

[joaotavora]

Anyway, as I said, my point is really not to introduce new bindings in Eglot. Users or third party packages, including daemonic distributions 😈 , that depend on Eglot can provide all the keybindings they want, though. So I think this should really work with the existing tooling offered by of C-h ., no need to reinvent the wheel:

C-h . runs the command display-local-help (found in global-map), which
is an autoloaded interactive compiled Lisp function in
`help-at-pt.el'.

It is bound to C-h ., <f1> ., <help> ..

(display-local-help &optional ARG)

  Probably introduced at or before Emacs version 22.1.

Display local help in the echo area.
This displays a short help message, namely the string produced by
the `kbd-help' property at point.  If `kbd-help' does not produce
a string, but the `help-echo' property does, then that string is
printed instead.

A numeric argument ARG prevents display of a message in case
there is no help.  While ARG can be used interactively, it is
mainly meant for use from Lisp.

[back]

[dgutov]

there should be some tool to display information available in a given point context, which would include diagnostics and summarized documentation. That can be done either via eldoc or via help-at-point.

Yes, okay.

But what about long-ish documentation for functions? Not one-liner summaries. Doesn't Eglot have a feature like that?

[joaotavora]

Doesn't Eglot have a feature like that?

Yes, though it's complicated. Many issues about it. There a custom variable for that eglot-put-doc-in-help-buffer I think. I would like to use eldoc exclusively, and let it do that management.
There's also eldoc-box in GNU Elpa, which started as a PR for eglot.

[dgutov]

Hmm. I'll have to try it.

But so far I have to say I liked the distinction between automatic one-lines being shown somewhere in the echo area, and long-form documentation displayed when I invoke some command manually.

And eldoc-box and similar approaches won't work in terminal (among other considerations), so I'm not sure we can standardize on this approach.

[joaotavora]

But so far I have to say I liked the distinction between automatic one-lines being shown somewhere in the echo area, and long-form documentation displayed when I invoke some command manually.

Sure, but that command belongs in eldoc, IMO.

And eldoc-box and similar approaches won't work in terminal (among other considerations), so I'm not sure we can standardize on this approach.

Agree with the first part, but the second part, "standarddize" , is whatever is more sensible. Like ediff uses a secondary frame on GUI and a window on terminal.

[dgutov]

Sure, but that command belongs in eldoc, IMO.

Why not. It could use an extension point, and a standard keybinding would be welcome.

[MarTango]

What is the current workaround for this? I've been using M-x display-local-help, but I'm not sure how to bind it to a key given the remap.

This? :

(define-key eglot-mode-map [remap display-local-help] nil) 

[muffinmad]

I'm using this:

(customize-set-variable 'help-at-pt-display-when-idle t)

When the hover info is shown, I can press C-g to see the diagnostic message.

It would be great to be able to cycle through all available messages in the echo area.

[joaotavora]

What is the current workaround for this? I've been using M-x display-local-help, but I'm not sure how to bind it to a key given the remap.
This? :

Yes, this should work.

When the hover info is shown, I can press C-g to see the diagnostic message.

This is clearly suboptimal. As some of you know, I'm working on fixing this correctly in Emacs's own eldoc.el.

It would be great to be able to cycle through all available messages in the echo area.

That's interesting functionality, but I think it should be made a part of either eldoc.el or Emacs's built-in messaging functionality.

[muffinmad]

It would be great to be able to cycle through all available messages in the echo area.

That's interesting functionality, but I think it should be made a part of either eldoc.el or Emacs's built-in messaging functionality.

Absolutely agree.

[nemethf]

The new, enhanced eldoc package solves the original issue, so I'm closing it.

[joaotavora]

Hey @nemethf , welcome back. If you could find and fix the related issue here about the out-of-date README.md doc that still talks about eglot-help-at-point, it would be icing on the cake ;-)