search

soulis-1256 / eagle.nvim

Show diagnostics and lsp info inside a custom window, following the mouse position
Apache License 2.0
232 stars 5 forks source link

Keyboard based workflow? #4

Closed lougreenwood closed 7 months ago

lougreenwood commented 11 months ago

Is it possible to trigger this just using the keyboard, I avoid using the mouse for anything in vim, but I don't see anything in the docs about keyboard usage.

Also, I wanted to mention I just posted an enhancement request to lsp-saga which I think you might find interesting. Basically my request there is what you seem to be planning, which is "diagnostics & LSP" in the hover a la VS Code.

https://github.com/nvimdev/lspsaga.nvim/issues/1349

Also really nice work here! I'm watching this closely as this is a feature I've missed from nvim for a long time, although I do think that integrating this with a wider set of LSP tools as part of something like lsp-saga offers a lot of scope to further enhance this as a part of a users workflow (as I describe in my above issue).

But maybe you already have similar plans and ideas? 😉

soulis-1256 commented 10 months ago

Hello, I read both your issue request here and on lsp-saga and I have some questions before I start thinking how to implement this. First of all, I'm going to make clear that im 99% sure that LSP info will be integrated to my plugin's window by next month without issues. I'm not particularly happy with a bigger plugin "copying" my hard work and not gettting recognition for what I've achieved (I'll probably live with it though). So with that said, let's talk keyboard workflow. There are three possible solutions: 1) Have a keybind that globally enables/disables this plugin, so that if it's enabled, it will automatically show hover info whenever you simply move the neovim cursor. 2) Have a keybind that only enables the plugin for the current cursor position (No cursormove event, no reaction). So the plugin will be disabled by default. 3) Have the plugin enabled by default, no additional keybinds. This would be the closest thing to what I already have with the mouse, but I'm pretty sure it would bring much more clutter compared to just using the mouse (because you can hide the mouse, but the cursor is always there).

Tell me what you prefer. I'm here for your feedback.

lougreenwood commented 10 months ago

Hi! 👋

First, thanks for the rapid reply, openness to my idea and willingness to engage 😃!

I'm not particularly happy with a bigger plugin "copying" my hard work and not getting recognition for what I've achieved (I'll probably live with it though). So with that said, let's talk keyboard workflow. There are three possible solutions:

This took me back a bit... mostly because I first mentioned the idea of combining LSP info & diagnostics to LSP Saga and when writing up an issue there, they had an Alternatives section - I remembered having already recently tried out your plugin and it seemed like a valid alternative and my goal was to make the case for adding it to LSP Saga, so I came over here to get a URL.

However, I then saw your recent changes to show diagnostics (IIRC before the recent changes it was actually LSP-only?) and I also realised that as the author, you might be interested in hearing this idea of "lets make it easy to inspect and act on the thing under the cursor" of which hoverhints.nvim in it's current and short-term goals (LSP info & diagnostics) seemed to align with and also be a subset of, so I mentioned it in my issue here for you to consider too.

Also, as much as I do prefer the simplicity of your solution, adding LSP info & diagnostics does lead to scope creep since - as a user - once we have diagnostics we may also want a selector for code actions for those diagnostics. I wanted to share my broader idea of "let's make it easy to inspect and act on the thing under the cursor" in case it inspired you too.

Additionally, once you have LSP info as a user we will also likely would naturally start to wonder how to:

Naturally, the above is now starting to look a lot like the current LSP Saga feature set.

Also, IMO (and as a user), ideally those implementations benefit from coming from the same plugin with the same visual styling - I already have Telescope popovers, telescope help, noice, legendary, which key, neo-tree help etc to deal with - minimising the number of popovers and their interactions patterns helps to minimise the mental noise and number of mental models & interactions patterns one needs to cognitively maintain.

So the reason I first reached for LSP Saga was because it already implements all of the things which a feature like my idea of "lets make it easy to inspect and act on the thing under the cursor" will likely require.

Also, IMO we're all copying it from VSCode, so I don't think there's any prior art to be precious - the more the merrier on journey towards finding powerful & unique interaction patterns & workflows.

However, with all that said - I understand why you want to pursue building out a USP and a unique offering with hoverhints.nvim and might see this as "copying", and this wasn't my intention, so sorry if it triggered those feelings.

TBH, I infer that maybe you have a goal to have a simple, clean and maybe somewhat opinionated implementation of LSP hover info, and I really like that. So assuming my inference is true and also assuming you have plans for expanding hoverhints.nvim out to a kind of general "LSP/Diagnotsic hover hints" (e.g the code action selections, hover definitions, hover implementations, refactor selections etc) then I would likely also choose this plugin over LSP Saga too 👍.

I hope that cleared that part up, my write up was, long & complex to try and communicate some subtlety & empathy for your situation, but the TLDR; is I hope your plugin can also grow and thrive and I wasn't trying to steal your ideas, TBH I didn't even realise that you had the idea for integrating LSP Info & diagnostics until I was almost finished with my issue for LSP Saga. I hope this adds some clarity and maybe helps to 🙇.

if you want to further discuss this idea of "let's make it easy to inspect and act on the thing under the cursor", I can create an issue if you'd like? I'm happy to explore ideas further if you would like that.

OK, now on to the scope of this issue 😅!

  • #1 Have a keybind that globally enables/disables this plugin, so that if it's enabled, it will automatically show hover info whenever you simply move the neovim cursor.

Maybe useful for others, but for me this would be too noisy. Maybe if there were a timeout and this only happened in normal mode (or allowed configuring which mode to auto-show info when moving, maybe with per-mode configurable timouts) it might work, but personally it wouldn't be my first choice.

  • #2 Have a keybind that only enables the plugin for the current cursor position (No cursormove event, no reaction). So the plugin will be disabled by default.

For me this is what I was thinking. I move the cursor around, nothing appears automatically, but I hit a key combo (shift-k) and the hover info appears. Essentially making a key combo an alternative to hover as the trigger. Maybe even allowing enabling/disabling mouse hover at all to force it to only keyboard only - but maybe that's an edge case and not really necessary in the real world.

  • #3 Have the plugin enabled by default, no additional keybinds. This would be the closest thing to what I already have with the mouse, but I'm pretty sure it would bring much more clutter compared to just using the mouse (because you can hide the mouse, but the cursor is always there).

Yeah, I agree... However, this did make me think of diagflow.nvim - i.e maybe having the popover always visible (but empty) in the top right (or configurable?) corner and it's auto-populated as a user mouses or cursors around.

Maybe it would also work with "#1 - Have a keybind that globally enables/disables this plugin, so that if it's enabled, it will automatically show hover info whenever you simply move the neovim cursor" it would help to minimise the noise by making the location consistent, so as I cursor or mouse around the code the popover auto-appears, but in the top right (maybe with some opacity, dimming, or as a smaller preview unless I press a key-combo (shift-k etc) and then it appears full screen.... IDK 🤷) - It's an interesting secondary idea, but IMO my primary preference would still be a simple toggle with key combo to hover/hide info about what's under the cursor.

Also, one last thing - I also realised that as hoverhints.nvim grows there's maybe some reasonable amount of overlap w/ trouble.nvim too... also this plugin looks very interesting too: https://github.com/piersolenski/wtf.nvim.

Thanks, keep up the great work! 💙

soulis-1256 commented 10 months ago

Whatever people tell me (if it makes sense), I will do my best to see it done. I have made a "new_features" branch and I have already started implementing the LSP info into my window. I agree with your opinion that having all these options into one window (probably with many keybinds involved) is a way to go. I don't know how much time it will take, but I'm positive it will be done, by me, or, by someone else (ie LSP Saga). Now, for the plugins you mentioned:

  1. trouble.nvim: I have used this plugin myself, and I have to say I don't really see the point in it given we already have a telescope way to see diagnostics (which is miles better in my eyes).
  2. diagflow.nvim: It's not a bad idea to have the window rendered on the side, as an extra option. Though this will definitely not work with the mouse (because until the mouse can reach the window, it will be already closed, due to how it's implemented), It can work with the keyboard workflow you've been talking about.
  3. wtf.nvim: I could work with the person who made this and have their options as options in my window. However, this will not be arriving soon, given the volume of work I already have ahead.

Lastly, I have created custom Discussions (#6 and #7), where we can continue this conversation. I would be glad to hear more ideas, or get a more detailed view on what you propose.