Hacker News Reader

Comment by necubi | Hacker News Reader

Not to be that guy, but emacs has had this for years via tramp.

As someone who used tramp and switched to VS Code, it's absolutely not the same thing. The difference is plugins work on the remote side of the connection without having to be aware they're in a remote connection. VS Code makes this work by having an agent running on the remote host. For the first time I actually got autocomplete and code jumping working without a horrendous amount of effort.

This is also true with TRAMP. Anything in core Emacs, and any package outside it that isn't aggressively poorly written, works transparently with TRAMP. The core utilities for interacting with the OS such as start-file-process are all TRAMP-aware. (Or more specifically, TRAMP provides file handlers which customize start-file-process)

One area I have found where TRAMP really suffers is when you have a relatively high-latency connection. I'm living on the east coast right now and connect to a dev box in Washington to work, and tramp is basically unusable. Every time you enter a folder in a project, emacs will stall for 1-2 seconds (unless the folder has been entered and cached before: unfortunately every time you restart emacs you'll have to go through it all again). If you've forgotten to disable autocomplete in a remote shell buffer, the first character you type will cause emacs itself to hang forever. There's unacceptable lag when opening and even navigating files. Good luck ever running grep or magit.

With VSCode on the other hand, I have no issues at all: couldn't even tell the project was remote.

I still use emacs (emacs -nw via ssh), but it's nowhere near VSCode's responsiveness and now I cant use GUI emacs. It's definitely a source of frustration :/

Yeah. TRAMP is magical, and everything just works. And has for years and years.

There is a comment right above yours that contradicts you: https://news.ycombinator.com/item?id=24561943

That comment doesn't contradict the post at all. If anything it supports that statement and then goes on to mentions that high latency connections are problematic.

High latency connections are a fact of life. If Emacs Tramp, for which development was started in 1998, when high latency connection were a lot more common, still has issues with high latency connections, that's not a glowing reference for its architecture.

Especially since it seems VSCode manages those connections better.

It's ok to admit your favorite tech has flaws, everything has them.

Not disagreeing with that. I am just saying that the previous post was that plugins don't have to be modified with Tramp and work transparently. The post referenced above does not disagree with that. Instead it says that tramp does not deal well with high latency connections. I think is important to be clear where the issue lies if one wants to get it fixed.

> The difference is plugins work on the remote side of the connection without having to be aware they're in a remote connection.

This is cool when the machine you are connecting to is more powerful than the one you are sitting on. This is far less cool when the machine you are connecting too is less powerful than your desktop (RPi or Beaglebone, for example).

In that case, why would you try to develop/compile remotely? Just target a different architecture.

In that situation, why not cross compile?

... and now he's the president. that shows ya!

Reply on news.ycombinator.com