How to support Inlay Hints in Rust

[e190]

https://rust-analyzer.github.io/manual.html#inlay-hints

And Lsp-mode also has this function
https://emacs-lsp.github.io/lsp-mode/page/lsp-rust-analyzer/#inlay-hints

[joaotavora]

We need a PR for this. A link to the protocol's standard would be a good start, and if it works like I guess it does (like diagnostics) I suppose it should be done via a special type of Flymake diagnostic with certain display properties.

[gmacon]

It looks like inlay hints were added in LSP 3.17, which was released a couple weeks back; they are described in Inlay Hint Request et seq.

[joaotavora]

For what it worth, I think it would annoy me to see the hints all the time.

I think I agree, yes. I was thinking that that behaviour_could_ be configured, for those who like it. But I would not make it the priority. The default version would be a hoverable symbol that shows something in the echo area when you mouse hover over it. Much like Flymake's default behaviour.

The big question here is when to request them. It would seem that these hints are particularly useful when browsing code in strongly typed languages, when there's not a lot of typing going on. So I was thinking the "current" function as the range (more or less easily gotten in most well-behaved modes with beginning-of-defun -> end-of-defun)

The keystroke to show them temporarily is also an interesting idea. But request and show them? Or just "reveal them"?

And you bring up the invalidation of hints. I think we have to invalidate aggresively. I fI have:

int32_t x;

blablabla();

x [inlay-hint: int32_t]+= y + 2;   

i can't risk having the stale inlay-hint int32_t remain if I decide I change the type to double

[skrytebane]

I think the way it's done in VS Code with editor.inlayHints.enabled set to offUnlessPressed is quite nice. That way, it only shows them for as long as you hold Ctrl+Alt. And as @nemethf says, it would be annoying to always show them. (I guess "holding Ctrl+Alt" doesn't quite fit with how it's done in Emacs, but a simple keybinding that shows all inlay hints and removes them on the next keypress, maybe?)

[joaotavora]

That's a good idea @skrytebane, I can imagine it being a very nice interface, which is really the biggest challenge here. But in Emacs, I'm not sure how one does that with keybindings. Can you start an Emacs bug report for this feature? I'd like to continue discussing there.

[skrytebane]

I'm guessing it's not possible at the moment, and if it was, it's probably not possible when running Emacs in a console. 🤷🏻

I just mentioned the keybinding used by VS Code. I think an Emacs-friendly keybinding could also be used, my point was just that it's nice to have a simple keybinding that shows all inlay hints until you press something else. Like how isearch shows all matches until you quit it.

[joaotavora]

I'm guessing it's not possible at the moment, and if it was, it's probably not possible when running Emacs in a console. 🤷🏻

Very true. Well, pity. The temporary enable will have to be some temporary mode mechanism.

[ShadowMitia]

Hello there!

I've been working on adding support for inlay hints in eglot, I have a WIP up on my repo here: https://github.com/ShadowMitia/eglot

I've just found this discussion, I'll try and apply some of the ideas here, but please let me know what you think, or what I should change. I've based this on the code lens PR, I figured the implementation would be close (I actually thought inlay hints and code lens were the same feature at first).

The implementation is still incomplete, there are bits of the standard I haven't got round to yet. Unless you want me to open PR now, I'll wait until the code is a bit more solidified.

If you want to check my code, just run M-x eglot-inlay-hint. To update rerun the command again to see the hints update.

[nemethf]

When you're ready, it is better to send the PR as a bug report to Emacs. Also the diff would be easier to read without the unnecessary white-space changes. Most probably this will be a legally significant contribution, so you might like to start the copyright assessment process now if you haven't completed your paperwork. Sometimes the process takes months.

[p00f]

I have submitted an improved version of @ShadowMitia 's patch here: https://mail.gnu.org/archive/html/bug-gnu-emacs/2023-02/msg00760.html

[p00f]

@joaotavora

The default version would be a hoverable symbol that shows something in the echo area when you mouse hover over it.

Having to do something defeats the purpose IMO: you can already see the type when you move your cursor to a variable (lsp "hover") and parameter names when you move your cursor to a function call. Inlay hints are for the whole buffer.

"hover" showing types:

"hover" showing parameter names:

[joaotavora]

Let's continue in the bug tracker discussion initiated by your bug report.

As far as I understand, inlay hints will show the type of many visible expressions at once, so it's different from the "hover" scenario.