3 ms·

VSCode has excellent git and github support (especially with the GitHub Pull Requests and GitLens extensions). In my workflow, it has surpassed anything Magit h

by ak217 2y ago

VSCode has excellent git and github support (especially with the GitHub Pull Requests and GitLens extensions). In my workflow, it has surpassed anything Magit had to offer. While I still use the command line git extensively, I've come to rely on VSCode for a lot of the more complex contextual information available when editing, resolving merge conflicts, staging, and contextual git history available in popups. I always leaned on emacs due to its versatility working in remote environments on the command line. I still use it occasionally, but for me the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin. It's a game changer and the best remote IDE experience I've ever had. Then Copilot came out and cemented the change. I think in general emacs and vi users learn to live with the UX and legibility issues of the software. I find vscode to be better at that. It strikes the right balance on a lot of things, in particular I find myself learning new things faster and with less frustration because the shortcuts, commands, and contextual information are more intuitive and in line with my expectations.

koito17 2y ago
> 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 2y 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 2y 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.
Ferret7446 2y ago
OSS Code's Git support is embarrassing compared to Magit. (Perhaps the proprietary extension is better, but I refuse to depend on proprietary tools for my core computing needs.) No line-by-line committing, no branch spinout/spinoff, no worktree support, no interactive rebase support, no reflog, the list goes on. I can see OSS Code being better for only novice Git users.
bananapub 2y ago
> VSCode has excellent git and github support ( no, it really really doesn't, compared to magit.

by ak217 2y ago

koito17 2y ago

> 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 2y 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 2y 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.

Ferret7446 2y ago

OSS Code's Git support is embarrassing compared to Magit. (Perhaps the proprietary extension is better, but I refuse to depend on proprietary tools for my core computing needs.) No line-by-line committing, no branch spinout/spinoff, no worktree support, no interactive rebase support, no reflog, the list goes on. I can see OSS Code being better for only novice Git users.

bananapub 2y ago

> VSCode has excellent git and github support ( no, it really really doesn't, compared to magit.