I've run into a bit of an odd problem trying to use lsp-mode.
My problem setup is as follows: I'm working on a C++ project on my computer, and I'd like to be able to use lsp-mode with it. The catch is that it's big, big enough that I can only build it on a remote VM with a bunch of resources.
The C++ lsp requires a compile_commands.json file, which needs to be generated by the build system. Our project is set up to build kinda weirdly, so I generate this file on the devbox via bear. At this point I should note that lsp-mode runs flawlessly if I ssh into the devbox and open emacs with emacs -nw.
Unfortunately, due to latency issues I really need to be able to edit the code locally and have all the nice lsp features while doing it. Therefore, I copy over the compile_commands.json to my local copy of the repo: it contains some absolute paths to the project on the devbox, so I update all of those via sed to point at the local copy.
I know this process can work, because I actually had it working flawlessly not two hours ago: complete parity with the ssh + emacs -nw experience. Unfortunately I kept messing around after that, checking out different branches, regenerating/copying the compile_commands.json, minor stuff like that. Now the process isn't working nearly as well as it used to, even after bringing the local and remote repos to the same states and running the same commands as the time when it worked.
I know that my way of bringing in the compile_commands.json is still doing something useful, because without it none of the lsp stuff works at all (as expected). However, the local lsp-mode is less functional than over ssh + emacs -nw, in at least a few ways
lsp-find-referenceswont find all, or sometimes even any, of the references to the symbol under point. In fact, if I try to find references to any member of a class it will just try to find references to the class itself: and even then it will only find the actual class definition itself, not even usages which I could detect via ctrl+flsp-find-definitionsometimes just straight-up wont work: displaying the following error in the minibuffercl-no-applicable-method: No applicable method: xref-item-location, nil- lsp spends a lot of time indexing in the background (updating with % progress in the minibuffer). This indexing takes a long time, and doesn't help at all once it has finished. Moreover, although the indexing creates a ".cache/clang" directory, every time I restart emacs it indexes the project all over again with no discernible performance improvement.
ssh + emacs -nw displays none of this behavior (it does create a cache dir but doesn't mentioning indexing in *Messages* at all, and quite frankly I'm baffled as to why.
The only difference I can think of in the one time I got it working was that lsp didn't auto-discover my local project- when I opened my first .cpp file, I got some sort of lsp menu at the bottom of my emacs window with four options asking me how to set the project root (I think I ended up hitting enter to take the default option). I have never seen that submenu again, despite having
- Deleted and re-cloned the local project
- Deleted all of my projectile projects
- Deleted my
~/.emacs.d/.local/etc/lsp-sessionfile - Uninstalled and reinstalled lsp (I use doom, so I did this by commenting out the "lsp" layer, running a
doom sync, uncommenting it, and thendoom syncing again)
Anyways, I was really hoping someone could help me out here. Figuring out how to properly delete all my lsp projects/caches and regenerate the project via that menu seems like a good starting point
