Joel Reicher <[email protected]> writes: > "Patrick Ohly" <[email protected]> writes: > >> I am using Tramp over ssh to do remote development in Go. This >> works reasonably well with gopls, thanks to everyone who has >> made this possible! Magit tends to be slow, so I gave up trying >> to use it. > > I think you have asked a few unrelated things here, so I'm just > going to answer everything as best I can (full disclaimer: I'm not > expert in some of this). > > I've heard magit makes excessive calls to git because git is > supposed to be cheap. I believe that cannot be understated: in my > opinion working with a remote git repo is a serious abuse of > git. It is designed to fetch everything from the remote to a local > copy, and all operations that would be expensive done on a remote > location become cheap(er) done locally. This is fundamental to > git's design, and remains true even if you run the code remotely.
That may very well be the root problem. However, in my case "remote" typically isn't that remote: it's a local desktop connected to the same 2.5Gbit Ethernet switch as my laptop. A proper network filesystem should be pretty fast, but then I face the challenge of teaching Emacs where to run commands. TRAMP makes that transparent. But it's not just magit. Just opening a file can take half a minute. >> With the hope of improving performance, I tried out sshfs. I ran >> into some shortcomings (bugs?) compared to ssh. If this is not >> the right place to report those then please ignore. I'm not >> subscribed to the list, please group-reply. But I can also >> subscribe, it that's required or preferred. > > If the bugs are with the TRAMP's sshfs method, this is the right > place. Yes, that's what I meant. I sometimes use sshfs directly and it works, but for the issue below I was using only the TRAMP sshfs method. >> I am using Emacs 30.1 with Tramp 2.8.1.3, go-mode 20250311.156, >> magit 20260401.2251 (all packages updated via elpa >> yesterday). gopls is installed in /usr/local/bin on the remote >> host. >> >> When I open a Go file, *Warnings* opens and I get: >> ⛔ Warning (tramp): STDERR not supported >> >> I don't have a workaround. Because this takes up screen space >> it's pretty annoying. > > How are you starting the server? And do you need to run it > remotely? As I said earlier a local git repo is better, but if > your language server needs more than just access to the repo it > becomes a slightly different matter. I am using lsp-mode, which automatically invokes the gopls binary. When editing a file opened via TRAMP, gopls runs on the remote host through ssh. >> When trying to start lsp, it fails: >> >> LSP :: The following servers support current file but do not >> have automatic installation: semgrep-ls-tramp >> golangci-lint-tramp gopls-tramp >> You may find the installation instructions at >> https://emacs-lsp.github.io/lsp-mode/page/languages. >> (If you have already installed the server check *lsp-log*). > > This is straying into LSP territory that might not be related to > TRAMP, but FWIW, are you using lsp-mode? If so I would suggest > eglot instead. I can try eglot. I don't remember why I chose lsp-mode. >> That's because it doesn't find the gopls command (visible in >> *lsp-log*). I found that I can work around that by creating a >> symlink to it in /bin. The reasons seems to be >> https://emacs.stackexchange.com/questions/81829/tramp-sshfs-remote-command-execution-doesnt-respect-tramp-remote-path-or-tra >> I think it should work the same as ssh and use the remote path >> settings. > > I personally would not do remote execution with sshfs; it's a > filesystem, and not a remote environment. Both the ssh and sshfs TRAMP methods support remote command execution through ssh. I found some prior discussion about whether the sshfs method should execute commands locally and the conclusion was that this would go against the goals of TRAMP. I concur, I am using TRAMP because all my tooling is installed on the remote host. In the case of sshfs, the mounted sshfs filesystem is only used for file transfers. My expectation was that both methods do remote command execution exactly the same way, with feature parity and perhaps even using the same code. But apparently that is not the case. >> magit gathers some information, but then fails with: >> >> magit-rev-diff-count: Wrong type argument: stringp, nil >> >> This is after some more warnings about stderr, so maybe related? > > You've lost me here, sorry. Can you give an MRE? I think there > might be too much going on. MRE = https://en.wikipedia.org/wiki/Meal,_Ready-to-Eat, i.e. a simple reproducer? A simple test would be to open a file in a remote git working tree with /sshfs:<host>/... instead of /ssh:<host>/... and then bringing up the magit status page. >> All of this works with tramp over ssh. > > This might come down to what I said earlier about sshfs not being > an environment. What does "environment" mean in this case? Does that refer to how both methods are implemented? Thanks, Patrick
