search

dgutov / diff-hl

Emacs package for highlighting uncommitted changes
GNU General Public License v3.0
928 stars 45 forks source link

Using Tramp and diff-hl causes emacs to stall #100

Open hisnawi opened 6 years ago

hisnawi commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

dgutov commented 6 years ago

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 commented 2 years ago

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 commented 1 year ago

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

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 commented 1 year ago

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.