5 ms·

I think you completely missed the context for the configuration issues in vim: I’ve been trying to get a working language server setup (so I can do things like

I think you completely missed the context for the configuration issues in vim: I’ve been trying to get a working language server setup (so I can do things like “go to definition”) and getting a setup that feels good in Vim or Neovim just felt like too much work.

rand0m4r 1y ago
It might have been a bit harder in the past, but with recent versions of neovim (>=0.11) it's less than 20 lines of configuration. I have quite a few keybindings to jump back and forth through errors and the default keybidings already include things like renaming, go to definition or listing references. I'd be more than happy to help you configuring it to your needs.
- neutronicus 1y ago
  FWIW, in my (emacs, C++) experience, writing the editor config is a relatively minor part of the yak-shaving required to have jump-to-definition on an actual work codebase. I had to get my project to emit compile_commands.json, get clangd, figure out which things about our build process clangd was not understanding from compile_commands.json and add them in .clangd. All to achieve a level of functionality significantly jankier than just opening the damn .sln file in Visual Studio. Once I did all that it was, as you say, very little actual stuff written in my .spacemacs. And probably could have been less if I had felt like figuring out how to get my windows emacs to find clangd on the path instead of giving up and just specifying full paths to everything. I only persevered because emacs (unlike Visual Studio) gives you all the necessary access to its internals to build LLM Tools around its LSP functionality.
  - galangalalgol 1y ago
    Whatever vim is in rhel 8 supports ale. Ale with rust has been great. Go to definition is flawless, all my conpile and clippy errors are underlined as I type and binding a key to ALECodeAction will apply the auto fix if it has one. Usually that is to import whatever I just used, which vscode would do automatically, but still its nice and having vscode use clippy as well as check bogs it down. And ale runs cargo-fmt on save. So yeah, nothing I'd wish different from it. Edit: upon further thought, I don't like having to move my hand to the arrow keys to select from the auto complete list, even if there is only one thing and then hit enter, rather than hitting tab to pick whatever is left.
    - davvid 1y ago
      > upon further thought, I don't like having to move my hand to the arrow keys ctrl-n and ctrl-p should let you select next and previous from the autocomplete menu while avoiding the arrow keys.
  - davvid 1y ago
    > I had to get my project to emit compile_commands.json, > get clangd, figure out which things about our build > process clangd was not understanding from > compile_commands.json and add them in .clangd That sounds rough. This is anecdotal, but in my Linux corner of the world, ccls has been an easier user experience as a C and C++ LSP since I've never had to resort to messing with flags in the generated file. I haven't used clangd myself, though, so I can't say either way, I just know ccls works well. By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere. The nvim snippet I use in my init.lua to setup ccls to work in that scenario is: vim.lsp.config('ccls', { init_options = { compilationDatabaseDirectory = 'build', }, }) vim.lsp.enable('ccls') My actual config does also contain a capabilities = ... argument that forwards the default_capabilities() from nvim-cmp, but you get the point. I hope that helps in case you're curious to give neovim another spin.
    - neutronicus 1y ago
      I did actually try CCLS first, but this was several years ago so it's possible that it may work better (something about our codebase was causing it to crash) - I should try it again. Lacking LSP didn't stop me from using spacemacs, though. Oh, no. emacs has an auto-complete mode that just chooses from a pool of symbols already present in open files and that turns out to be Good Enough for me to prefer editing code there vs Visual Studio, IntelliSense be damned. My employer furnished me with a beefy enough workstation that I can have Visual Studio open (to semantic search the whole codebase for stuff I don't already known where to find and to build/run/debug) alongside emacs (for editing and general code browsing when I know where definitions live).
- alfalfasprout 1y ago
  This. Now that LSPs are natively understood by neovim it's a very painless process. Especially if using mason to fetch the language servers.
deleted 1y ago
[deleted]
soraminazuki 1y ago
Getting LSP to work on recent versions of Neovim is one plugin + one line of configuration. Here are the steps for enabling clangd: 1. Install nvim-lspconfig plugin 2. Add `vim.lsp.enable("clangd")` to init.lua You can even enable LSPs on a per-project basis by taking advantage of the revamped exrc feature: 1. Add `vim.opt.exrc = true` to init.lua 2. Add `vim.lsp.enable("clangd")` to $projectdir/.nvim.lua
- nerdponx 1y ago
  You don't even need the plugin nowadays, you can just go to the lspconfig repo and copy paste the default config if you don't know where to start. lspconfig was an incredible effort, and I consider it a good thing that it is now fading into a simple repository of default configurations.
  - soraminazuki 1y ago
    I'd say that having a plugin with default configurations that is kept updated is a necessity. Because that's what enables me to use LSPs with a single line configuration.
    - nerdponx 1y ago
      Serious question: how often does a sensible default configuration need to change? I think I have used the same jedi-language-server config across projects and computers since before Neovim had a built-in LSP client, with the only changes being on the Neovim side gradually migrating to new features as they appeared. Obviously do whatever works for you. But I do feel like most LSPs shouldn't need more than a few lines that you set and forget.
      - soraminazuki 1y ago
        Well, LSPs come and go so that's one source of churn.

rand0m4r 1y ago

It might have been a bit harder in the past, but with recent versions of neovim (>=0.11) it's less than 20 lines of configuration. I have quite a few keybindings to jump back and forth through errors and the default keybidings already include things like renaming, go to definition or listing references. I'd be more than happy to help you configuring it to your needs.

neutronicus 1y ago
FWIW, in my (emacs, C++) experience, writing the editor config is a relatively minor part of the yak-shaving required to have jump-to-definition on an actual work codebase. I had to get my project to emit compile_commands.json, get clangd, figure out which things about our build process clangd was not understanding from compile_commands.json and add them in .clangd. All to achieve a level of functionality significantly jankier than just opening the damn .sln file in Visual Studio. Once I did all that it was, as you say, very little actual stuff written in my .spacemacs. And probably could have been less if I had felt like figuring out how to get my windows emacs to find clangd on the path instead of giving up and just specifying full paths to everything. I only persevered because emacs (unlike Visual Studio) gives you all the necessary access to its internals to build LLM Tools around its LSP functionality.
- galangalalgol 1y ago
  Whatever vim is in rhel 8 supports ale. Ale with rust has been great. Go to definition is flawless, all my conpile and clippy errors are underlined as I type and binding a key to ALECodeAction will apply the auto fix if it has one. Usually that is to import whatever I just used, which vscode would do automatically, but still its nice and having vscode use clippy as well as check bogs it down. And ale runs cargo-fmt on save. So yeah, nothing I'd wish different from it. Edit: upon further thought, I don't like having to move my hand to the arrow keys to select from the auto complete list, even if there is only one thing and then hit enter, rather than hitting tab to pick whatever is left.
  - davvid 1y ago
    > upon further thought, I don't like having to move my hand to the arrow keys ctrl-n and ctrl-p should let you select next and previous from the autocomplete menu while avoiding the arrow keys.
- davvid 1y ago
  > I had to get my project to emit compile_commands.json, > get clangd, figure out which things about our build > process clangd was not understanding from > compile_commands.json and add them in .clangd That sounds rough. This is anecdotal, but in my Linux corner of the world, ccls has been an easier user experience as a C and C++ LSP since I've never had to resort to messing with flags in the generated file. I haven't used clangd myself, though, so I can't say either way, I just know ccls works well. By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere. The nvim snippet I use in my init.lua to setup ccls to work in that scenario is: vim.lsp.config('ccls', { init_options = { compilationDatabaseDirectory = 'build', }, }) vim.lsp.enable('ccls') My actual config does also contain a capabilities = ... argument that forwards the default_capabilities() from nvim-cmp, but you get the point. I hope that helps in case you're curious to give neovim another spin.
  - neutronicus 1y ago
    I did actually try CCLS first, but this was several years ago so it's possible that it may work better (something about our codebase was causing it to crash) - I should try it again. Lacking LSP didn't stop me from using spacemacs, though. Oh, no. emacs has an auto-complete mode that just chooses from a pool of symbols already present in open files and that turns out to be Good Enough for me to prefer editing code there vs Visual Studio, IntelliSense be damned. My employer furnished me with a beefy enough workstation that I can have Visual Studio open (to semantic search the whole codebase for stuff I don't already known where to find and to build/run/debug) alongside emacs (for editing and general code browsing when I know where definitions live).
alfalfasprout 1y ago
This. Now that LSPs are natively understood by neovim it's a very painless process. Especially if using mason to fetch the language servers.

deleted 1y ago

[deleted]

soraminazuki 1y ago

Getting LSP to work on recent versions of Neovim is one plugin + one line of configuration. Here are the steps for enabling clangd: 1. Install nvim-lspconfig plugin 2. Add `vim.lsp.enable("clangd")` to init.lua You can even enable LSPs on a per-project basis by taking advantage of the revamped exrc feature: 1. Add `vim.opt.exrc = true` to init.lua 2. Add `vim.lsp.enable("clangd")` to $projectdir/.nvim.lua

nerdponx 1y ago
You don't even need the plugin nowadays, you can just go to the lspconfig repo and copy paste the default config if you don't know where to start. lspconfig was an incredible effort, and I consider it a good thing that it is now fading into a simple repository of default configurations.
- soraminazuki 1y ago
  I'd say that having a plugin with default configurations that is kept updated is a necessity. Because that's what enables me to use LSPs with a single line configuration.
  - nerdponx 1y ago
    Serious question: how often does a sensible default configuration need to change? I think I have used the same jedi-language-server config across projects and computers since before Neovim had a built-in LSP client, with the only changes being on the Neovim side gradually migrating to new features as they appeared. Obviously do whatever works for you. But I do feel like most LSPs shouldn't need more than a few lines that you set and forget.
    - soraminazuki 1y ago
      Well, LSPs come and go so that's one source of churn.