bug#61066: [PATCH] Add inlay hint support to eglot

[Dimitri Belopopsky]

Hello,

I don't have much experience with hacking emacs, but I was thinking the current code could also be reused

for the code lens LSP feature. Maybe there are other features that could be done with the same kind

of setup?

This (to me anyway) would probably mean eldoc isn't the best option for a more general solution.

Though I expect having overlays for eldoc would be beneficial as well.

I don't really know which is best between a library or integration inside flymake. I might try out both

ideas, as I have no experience with either of them. My guess flymake sounds easier to implement, but

a support library could probably be more flexible for reuse?

Dimitri

On Thu, 26 Jan 2023 at 13:29, João Távora <joaotavora@gmail.com> wrote:

On Thu, Jan 26, 2023 at 6:28 AM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Dimitri Belopopsky <dimitri@belopopsky.com>
> Date: Wed, 25 Jan 2023 23:34:02 +0100
>
> I've been working on adding support for inlay hints inside eglot using overlays.
> Here is a working patch, but I'm still missing a few things:
>
> - I can't figure out a way to show the hints on a document without causing lags or timeouts from the lsp
> server
> - I'm currently updating the hints by sending the whole file each time (to make sure all hints get updated
> correctly). I'm not sure on how to make this more efficient (or if it even necessary).
>
> On the implementation side:
> - implemented with overlays as a minor model, enabled by default
> - shows all hints supported by the protocol
> - there is a customisation to disable the minor mode if the user doesn't want the feature
>
> I'd love to get a few points to finish this patch, and of course any ideas and feedbacks are welcome!

Thank you for working on this important feature.

AFAIU, inlay hints provide information of the same kind as ElDoc and
in similar manner from the display and UX POV.  So I think this
feature should work via ElDoc, not as a separate from-the-scratch
implementation.  ElDoc is already capable of using Eglot-supplied
information, so perhaps the only feature we need to add is the
capability of ElDoc to (optionally) display the information in
overlays near point.  (I thought we already had such a capability in
eldoc.el, but it looks like I was dreaming, because I cannot find it
there.)

The advantage of basing this on ElDoc is that then we will be able to
provide similar features from information sources other than Eglot.

João, WDYT?

I think you're mostly right in your analysis.  I also think this should be provided

via some LSP-agnostic infrastructure and not as a separate from-the-scratch

implementation, as you put it. This is (and was) also my stance in other similar

matters.

The devil is in the details, of course.  Is eldoc.el the right infrastructure

for it. What augmentation does it need, if any?  Are these augmentations

practical given the relative size, complexity and history of eldoc.el? Isn't

an "inlay.el" or a "little-hint.el" support library a better choice? Or maybe

flymake.el with it's use of overlay-based annotations is also acceptable

here?  I don't (yet) have answers to these questions.

Of course the existence of this prototype by Dimitri is certainly

No Bad Thing and a good starting point.

João