window 2 = neovim with OCaml lsp server support working
Now, when I see an error in the dune build -w window, I manually navigate to it in the nvim window and fix it there.
Is there a way in nvim window to auto get list of errors? (i.e. something that works with quick fix, cnext/cprev, or …). The current setup shows all errors/warnings in CURRENT buffer. However, if there are no errors in current buffer & an error elsewhere, I need to manually navigate. I would like to be able to just hit a key and “jump to next dune build error”
I don’t have a map that can jump to diagnostics across buffer, I use Telescope for that. So :Telescope diagnostics (or a map to that command) will bring up a window with the list of diagnostics and a code preview panel, and you can use that to jump to the error. Fzf lua has a similar functionality ( diagnostics_document
vs diagnostics_workspace) but again it’s a picker, not a single quick jump command.
By looking at these 2 plugins and how they use the diagnostics and other related APIs, it should be possible to achieve what you are looking for.
I don’t think we would need to reach out to merlin, the lsp integration should have all we need.
Personally I have vim.lsp.buf.hover() mapped to K but that brings a floating window, I don’t have that in my status line.
The exact solution would probably depend of the status line plugin you are using, and (I’m guessing) would involve implementing a lsp-handler (unless of course, your status line plugin already offer something like that.)
I’m not sure I would go that way. To avoid hammering the with type information requests, you will probably put the refresh of the type under the cursor in an autocmd attached to an event like CursorHold. At that point, isn’t a very simple mapping like K with a floating window quicker than waiting for the updatetime to lapse?
An other advantage of the window: to successive call to the hover() function will give focus to the window, so it become easy to read long type declaration like a full module.
It’s probably not worth it anymore, I’m still in the testing phase, but I’ve migrated to https://astronvim.com/
I used to have a highly currated set-up, but it turns out:
Other people are better than me at creating advance neovim set-up, and I’d be much better tweaking theirs than maintaining mine.
Thanks to ocaml-lsp , ocaml support in neovim has nothing special. You’ll get a first class experience by following any advance config tutorial or using one of the preconfigured configurations.
Astro, Lunar, and NvChad are all solid options I’ve considered. (I haven’t tested, or even open the GH pages of everything on that list, so the quality of the rest may vary)
I’ve tried LunarVim. I thing I did not like about these setups (not picking on Lunar in particular) is that they often pull in so many things that I can no longer understand what does what. It’s like this big ball of string that I can’t untangle into individual threads.
FWIW I use doom-nvim, here is my fork (I’ve been upstreaming most of my changes slowly though): GitHub - edwintorok/doom-nvim: A Neovim configuration for the advanced martian hacker.
One thing that doesn’t work perfectly is support for ‘.mli’ files: I can either get tree-sitter to recognize .mli files as separate syntax, or have a working LSP in .mli files, but not both. (changing the filetype of to ocaml.interface breaks ocaml-lsp for me: it says “can’t find document with uri”, I didn’t dig deeper into why).
Here is the particular piece of code that maps K to lsp hover: doom-nvim/init.lua at main · edwintorok/doom-nvim · GitHub
, ocaml support in neovim has nothing special. You’ll get a first class experience by following any advance config tutorial or using one of the