0

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

  1. lsp-find-references wont 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+f
  2. lsp-find-definition sometimes just straight-up wont work: displaying the following error in the minibuffer cl-no-applicable-method: No applicable method: xref-item-location, nil
  3. 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

  1. Deleted and re-cloned the local project
  2. Deleted all of my projectile projects
  3. Deleted my ~/.emacs.d/.local/etc/lsp-session file
  4. Uninstalled and reinstalled lsp (I use doom, so I did this by commenting out the "lsp" layer, running a doom sync, uncommenting it, and then doom 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

0

So in the meantime my OS actually died and I had to reinstall it, which involved re-installing things like Emacs. Fortunately my home folder was left intact, and I took this as an opportunity to try and get that menu again.

I ended up succeeding, though it didn't restore the missing functionality: that's probably all that anyone could have hoped to help me with anyways though :D

I'm sure all these steps aren't necessary, but I

  1. Rebuilt emacs from source
  2. Removed my ~/.emacs.d and re-cloned doom (I kept my old dotfiles though)
  3. Renamed all the .git folder to make sure the project wasn't being discovered using those
  4. Renamed the compile_commands.json file so that the project couldn't be discovered with that (thanks to vidjuheffex on reddit for suggesting this)

Unfortunately, the LSP functionality was still broken, though in a slightly different way. It no longer goes through a long indexing process, which is good. Furthermore, I've just noticed (perhaps it was there all along, but I'm surprised that I didn't find it earlier if it was) an lsp-log buffer which is reporting a bunch of errors: all sensible, from what I can tell, and related to my not having copied over the build directory from the remote machine (not really an option, it's over 30gb)

I still have no idea how things were working so perfectly for a beautiful moment... that's just life I guess :/

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.