new | ask | show | jobs
neutronicus 3 days 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 3 days 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 3 days 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 3 days 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 9 hours 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).