uivonim VS vim-lsp-ale

I’ve never used Redux, just haven’t cared to look into it for any projects I’ve worked on, but from a quick glance at an example it seems like it could be useful/convenient. Although then again you can write an event dispatcher in like 30 lines of TS, probably with redux-like state with a little extra work, although I’ve never tried, and that could be a bad idea in practice idk.

Instead, Nvim provides an RPC protocol that may be implemented by external GUIs. For example, there exists a plugin that embeds Nvim into Firefox when editing textboxes, GUIs that leverage Nvim's multigrid support to support smooth scrolling, translucent popups, minimaps, etc. such as Uivonim, Goneovim and Neovide, and more.

Porting my (forked, so not all my work) text editor uivonim to use Tauri instead of Electron. PR for those curious is here: https://github.com/smolck/uivonim/pull/336

Of course, I'm biased, since I work on a GUI frontend to neovim written in electron (that I forked from a project that already used electron), but I have found that it's not as bad as people make it out to be, or at least that it doesn't have to be that bad. I would like to get rid of it though if I can, maybe by doing the rendering with wgpu-rs and GUI things with egui.

I came up with this idea one day as something I could add to uivonim and the result was kinda cool; just thought I'd clean it up a bit and share. Not sure if I'll ever end up adding this for-real, but it's at least a little fun to play with ;)

ALE can use LSP as well. And if you are using vim-lsp, you can use the same instance of server for both with vim-lsp-ale bridge plugin.

Don't you need vim-lsp-ale for that? It puts lint results from vim-lsp into ALE's interface so ALE doesn't need to run a second lsp server. Which seems to be another way of saying ALE uses it as a source.

However; apparently this causes two LSP's to run. Instead of nvim's default lsp; there is also prabirshrestha/vim-lsp and mattn/vim-lsp-settings that runs LSP's. There is rhysd/vim-lsp-ale to fix the concurrent LSP running between Ale and vim-lsp, and shun/ddc-vim-lsp which integrates vim-lsp with ddc.vim

See comment here for a setup with vim-lsp. Add ale for lint support and vim-lsp-ale to put lsp linting into ale.

ALE is primarily for linting (although it may also serve as basic LSP client). The protocol itself is for code completion, hover tips, navigation, workspace symbols, finding references, highlighting, renaming, reformatting, refactoring etc. And also diagnostics (which you can integrate with ALE via vim-lsp-ale).

I looked at this earlier and was unsure if this is in lieu of ALE or in addition to ALE. I saw a post about also needed - How can I use ALE and vim-lsp together? When I looked into vim-lsp-ale I was unsure about how to configure PLS for perl.

Try vim-lsp-ale to get vim-lsp lint errors to show in ale. You should turn off all other linters unless you actually need them.

Sorry I should have mentioned I'm using ALE for linting/fixing. Would I have to remove ALE to use Neovim's native LSP, or use a plug-in like this I'm assuming?

To me "integrated" means I do everything from one application -- no building in the shell etc. I think the biggest knock against "integrated" is when vim plugins don't work together (like ale and lsp before vim-lsp-ale).

Hello! I thought I'd mention this plugin to people, as people might not know about it. rhysd on GitHub has put together a plugin that connects vim-lsp to ALE, completely without much, if any, help from me. I think it's pretty cool, and it could be useful for someone. Check it out.