search

weilbith / nvim-code-action-menu

Pop-up menu for code actions to show meta-information and diff preview
MIT License
578 stars 19 forks source link

Weird Request: Extract the code for visualizing `WorkspaceEdit` diffs into a new plugin? #33

Open IndianBoy42 opened 2 years ago

IndianBoy42 commented 2 years ago

I am trying to implement some code/a plugin for live visualizing rust-analyzer structural search and replace. (https://github.com/rust-analyzer/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#structural-search-replace-ssr). It basically uses LSP to do 'smarter' search and replace using semantic information rather than just textual. It returns a WorkspaceEdit that represents the transformation. I was looking into how to visualize this as some kind of preview, when I realized that that is one of the features of this plugin (code actions afaict use WorkspaceEdit as well).

If I am developing this just for myself then I could try and reverse engineering your API and depending on your plugin. But I wonder if you'd be interested in extracting it to a new plugin nvim-viz-workspace-edit or something so that others can use it?

weilbith commented 2 years ago

100%

Totally makes sense and is also kinda planned (though that doesn't mean a lot). For example do I intend to use it to preview the normal LSP rename feature (kinda as you do). I'm currently in a dead-lock with this plugin. I try to rework it on all ends and make it more generic. So should it be possible to use any kind of LSP client (native, coc, vim-lsp, ...) and also any kind of front-end (telescope [cursor theme/new theme?], vim.ui.select, fzf-preview, ...). In result this would mean the only core feature of this plugin would be to provide the extended menu list entries, the summary and the diff preview. It would be then bracket wrapped by generic interfaces for back- and front-end. Implementing these interfaces would be the glue code to all the other plugins. To achieve this I would like to have better language support in an object oriented manner. Though it is not the holy grail it would feel good here. After all it would be at least very very helpful to have some proper type system and get support by your editor. This becomes very handy when having the back-end and front-end interfaces and having to implement them. Though this is all possible in Lua without very nice code, I don't like it too much, so I'm not motivated to do it right now. I'm coding all day professionally. Working on private projects does then need a big motivational factor so I can enjoy it. I'm thinking of writing a Rust library that can be used as native Lua module then. There are also nice crates (libraries) in Rust for the LSP protocol. But it also includes a lot of friction and isn't the perfect solution for the problem. After all, the diff preview generation code definitely needs a completely rework. It has bugs, reads horrible and could also look better (in-line diff?).