3 ms·

> the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin Have you tried using TRAMP? Depending on the specific bac

> the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin Have you tried using TRAMP? Depending on the specific backend chosen (ssh, scp, ...) it has varying levels of speed, but I have found it sufficient for my needs. Regarding Copilot, that's an interesting use case. It makes me wonder if other editors have extensions that try to recreate this experience. I wouldn't be surprised if Copilot is the killer feature of VS Code nowadays.

screcth 3y ago
TRAMP is unusable if you have a high-latency connection. The UI thread blocks for a few seconds after every operation, which are really frequent if you use a complex configuration. The remote SSH plugin makes high-latency connections bearable, it's not perfect, but IO operations run in the background and so the UI thread does not block. I expect rewriting Emacs to use async IO to be a massive effort. It's difficult to write async code in Elisp.
ak217 3y ago
TRAMP is unusable for my needs and doesn't really implement the remote IDE paradigm at all. I would argue that no IDE really implements the remote IDE paradigm aside from VSCode with the remote SSH plugin; it sets a new benchmark. I've tried several other IDEs and I haven't seen anything that works nearly as well. Take a look at the diagram here: https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh - you will see that VSCode does not simply connect to the remote computer to read and write some files. It installs an entire VSCode server - seamlessly to the user every time they connect to a remote - that keeps track of all project facilities, shells, extension accessory runtimes, takes care of embedded or computationally heavy tasks like compiling, building, running project-wide code analysis tools, etc. while keeping all settings, editor windows, and accessory panes local (which is critical for UX and latency). VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions. These latency optimizations and offloads are not ad hoc; they are rooted in VSCode's origin as a browser-based IDE, and make use of the LSP and other architectural features that simply don't exist in Emacs because nobody really thought deliberately about running the extensions at an arm's length from the editor UI in Emacs, using an async protocol that doesn't allow extensions to impact core UI latency. A routine issue with TRAMP is that some unrelated plugin makes editing very slow and subject to random freezes because it expects low-latency I/O to the file being edited and to other accessory files next to it. This is a major issue that absolutely kills editing UX and confidence. It doesn't really happen with VSCode (worst case, the red squiggles show up a few seconds late), and just as importantly, the entire project behaves predictably because it's not just TRAMP running on the remote but the entire IDE infrastructure. Ironically, I think Emacs' origin on X-based systems foreclosed on the architectural possibility of a clean separation of concerns that can be seen in browser-based IDEs; it would be wildly disruptive to the package ecosystem.

screcth 3y ago

TRAMP is unusable if you have a high-latency connection. The UI thread blocks for a few seconds after every operation, which are really frequent if you use a complex configuration. The remote SSH plugin makes high-latency connections bearable, it's not perfect, but IO operations run in the background and so the UI thread does not block. I expect rewriting Emacs to use async IO to be a massive effort. It's difficult to write async code in Elisp.

ak217 3y ago

TRAMP is unusable for my needs and doesn't really implement the remote IDE paradigm at all. I would argue that no IDE really implements the remote IDE paradigm aside from VSCode with the remote SSH plugin; it sets a new benchmark. I've tried several other IDEs and I haven't seen anything that works nearly as well. Take a look at the diagram here: https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh - you will see that VSCode does not simply connect to the remote computer to read and write some files. It installs an entire VSCode server - seamlessly to the user every time they connect to a remote - that keeps track of all project facilities, shells, extension accessory runtimes, takes care of embedded or computationally heavy tasks like compiling, building, running project-wide code analysis tools, etc. while keeping all settings, editor windows, and accessory panes local (which is critical for UX and latency). VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions. These latency optimizations and offloads are not ad hoc; they are rooted in VSCode's origin as a browser-based IDE, and make use of the LSP and other architectural features that simply don't exist in Emacs because nobody really thought deliberately about running the extensions at an arm's length from the editor UI in Emacs, using an async protocol that doesn't allow extensions to impact core UI latency. A routine issue with TRAMP is that some unrelated plugin makes editing very slow and subject to random freezes because it expects low-latency I/O to the file being edited and to other accessory files next to it. This is a major issue that absolutely kills editing UX and confidence. It doesn't really happen with VSCode (worst case, the red squiggles show up a few seconds late), and just as importantly, the entire project behaves predictably because it's not just TRAMP running on the remote but the entire IDE infrastructure. Ironically, I think Emacs' origin on X-based systems foreclosed on the architectural possibility of a clean separation of concerns that can be seen in browser-based IDEs; it would be wildly disruptive to the package ecosystem.