Using Tramp and diff-hl causes emacs to stall

[hisnawi]

Not sure what kind of debug i need to do to figure out the issue but I know that when disabling diff-hl browsing remote directories and files are ok

[dgutov]

For Dired, you can try (add-hook 'dired-mode-hook 'diff-hl-dired-mode-unless-remote) instead of straight diff-hl-dired-mode, like described in its commentary.

Files have the same problem?

[hisnawi]

Works much better.
Is it a known issue? Do you need this issue to stay open to debug the main issue farther?

[dgutov]

Yup, let's keep it open.

You should probably report it to Tramp, though. As far as diff-hl-dired is concerned, the remote calls should be asynchronous, and thus avoid freezing the UI. Not that it's going to matter much if the alternative is seeing the indicators with a big delay.

[jeslie0]

I think I might be able to help fix this problem. I know this is four years later, but it would be useful to know what version of Emacs you are using, as well as what tramp method you used (did you connect with SSH /ssh:user@addr:). I will try and recreate the problem myself.

[dgutov]

@jeslie0 It's 1 more year later 😬, but if you wanted to look into this, I've just reproduced it myself:

• Emacs is latest (built from master),
• Tramp method is indeed SSH,
• The remote host is slow or distant or both (slow to respond anyway).

There are some interesting logs in the issue linked from Doom's repo as well. What happens is Tramp creates a new connection for every asynchronous process invocation. And there are ~5 of them during vc-git-dir-status-files. So while the function itself is asynchronous, if the connection is slow enough, the Tramp implementation spends time establishing new connections (and that part happens synchronously).

A little more information in comments here: https://emacs.stackexchange.com/questions/3945/eshell-doesnt-reuse-tramp-connection-for-remote-subprocesses, and in this report here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13677.

This one might be tangentially relevant as well: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56342

Basically, it seems like Tramp only caches one connection to the host, and reuses it for synchronous calls (but not asynchronous ones). But doesn't do any more advanced connection pooling, or even just keep a second connection around. Looks like what is needed is "just" someone to dig in and implement that.

[dgutov]

People say setting up ControlMaster helps to some extent (https://stackoverflow.com/questions/56105716/magit-over-tramp-re-use-ssh-connection), but Tramp still has to make extra round-trips.