ggtags does not play well with tramp -- emacs freezes multiple times

Question

I've recently started to use tramp to edit a codebase that's two ssh hops away from me I was initially very happy with the experience, given how transparent everything was.

I use magit and ggtags and, after some initial trouble, I managed to configure the environment in order for emacs to find the proper path.

However, after using this setup for some time, I noticed that ggtags and tramp really do not play along very well.

Every few seconds, when I type in some symbol that ggtags thinks it might recognize, it kicks in, calling tramp to access GTAGS and friends, making me wait for some good seconds before unfreezing emacs and letting me type again. This would be OK if it wasn't for the fact that emacs doesn't always come back. Very often, if I keep typing while emacs is frozen, things probably get into some sort of loop and it keeps frozen for wayy too long.

I'm not sure if it keeps stuck forever, but for several minutes that's for sure. To unfreeze it, I have to repeatedly hit C-g. Whenever I do this, I get a message more or less like

error in process filter: Quit

which seems to indicate that some sort of filter process is what gets stuck.

Any idea what I could do to mitigate this?

At the moment, I just disable ggtags when I'm typing in code, but that's really less than ideal, since I rely a lot on ggtags to navigate on the codebase.

I also though about downloading the GTAGS files, but I avoided doing that since these files are several GB and I also don't even know how that would work.

---

A little bit more about my setup

Some more details about my setup and what I've been trying out so far. The codebase I'm working on is a somewhat large C++ codebase. Compiling it in my local machine takes around 40-50min. My remote work machine is way more powerful and is able to compile it in 25-30min. Also, it has a lot more memory available, which means I don't have to keep an eye on the memory consumption like I do in my local machine.

To access my remote machine I have to, first, access the institution's ssh servers to, then, from it, access my machine and then work on it. So far, I've been using emacs through X forwarding, which works surprisingly well, but the problem is that the connection isn't always the best, given that every other employee has to access their own machine through the same ssh server. If the connection goes down, I have to kill my ssh session and reconnect to it, losing all my buffers in the process. Also, input lag can get really bad sometimes, which considerably slows me down.

To summarize, here are my options:

• emacs through X forwarding, which works well, but isn't super reliable
• work locally, which is the best for editing, but my computer isn't powerful enough to compile the project in a satisfactory manner
• local emacs with tramp, which allows me to edit locally, but compile remotely and works pretty well, besides ggtags not playing along
• local emacs pushing the code every once in a while to compile in the remote machine, which would really slow me down compared to any of the other options

Answer 1

For now, after a few days of experience, what has worked for me was simply disabling ggtags-mode for remote files.

The ggtags README recommends1 the following hook to automatically activate ggtags for some major modes (including C++):

(require 'ggtags)
(add-hook 'c-mode-common-hook
          (lambda ()
            (when (derived-mode-p 'c-mode 'c++-mode 'java-mode 'asm-mode)
              (ggtags-mode 1))))

I modified it so that it only enables ggtags if the current buffer is not remote, following this answer's instructions:

(add-hook 'c-mode-common-hook
          (lambda ()
            (when (and (derived-mode-p 'c-mode 'c++-mode 'java-mode 'asm-mode)
                       ; only activate ggtags if not remote
                       (not (file-remote-p default-directory)))
              (ggtags-mode 1))))

The ideal would be for ggtags to have some option of disabling passive queries like checking a type when the cursor is over an identifier. Until then, this is the best I've got.