4 ms·

I do think that keyboard optimized workflows are not for everyone; you should use what works best for you! However, Emacs distributions like Doom Emacs or Spac

I do think that keyboard optimized workflows are not for everyone; you should use what works best for you! However, Emacs distributions like Doom Emacs or Spacemacs are definitely more approachable and featured OOTB than vanilla Emacs. For me, the benefit of Emacs is that it's a single environment I can do everything in. I also am the type to enjoy messing with my workflow. IMO most of that can be replicated with VS Code in a much more user friendly manner (VS Code remote editing blows TRAMP out of the water), with the caveat that multiple projects means multiple windows, it's difficult to have an entirely mouseless workflow, and in general it's less customizable than Emacs. I personally never bothered to learn Emacs keybindings and instead use Vim keybindings in every editor I touch; VS Code and Emacs both have excellent Vim plugins. Honorable mention: Neovim. It is lighter weight than either Emacs or VS Code but can still have pretty much all the bells and whistles. Definitely cool if you prefer to live in a terminal.

sokoloff 4y ago
> VS Code remote editing blows TRAMP out of the water I’ll have to try VSCode in this area, but Tramp seems pretty awesome to me so I’m trying to think how it could be blown out of the water.
- kfajdsl 4y ago
  In the "just works" department mainly, especially in regards to other packages playing nice with tramp.
ParetoOptimal 4y ago
> VS Code remote editing blows TRAMP out of the water One place emacs has a huge advantage is it doesn't use hardly any resources in the docker container. The vscode remote server instance uses a constant 15%-30% however. In real world terms this means a compile that takes 1 minute for me takes 2 minutes for my coworkers that use vs code. There are many potential confounding factors that could affect the performance discrepancy of course, but I think it's still useful given I can't think of many other plaform differences and that it's consistent amongst my coworkers.
- kfajdsl 4y ago
  This is true; not having that remote server has its pros and cons. VS Code is also just in general slower than Emacs haha. I'm surprised the difference is that much though!
zelphirkalt 4y ago
> VS Code remote editing blows TRAMP out of the water I think it is not that black & white. Recently I've used tramp to dial into a server via SSH and there into a docker container and directly edit files inside. I don't think VSCode can do the same inside a shell it starts. Sure it may be able to open an SSH shell and then from there you might be able to type in some docker exec command. But that is not the same as tramp into docker container on a remote host via SSH for the following reasons: When I use keyboard shortcuts from inside that tramp shell, Emacs understands, that it happens inside the tramp context and for example will only show me files inside that docker container, when I do a find-file. Should I decide to run an rgrep from that context, it will show me results in that context. If I click the findings of that rgrep, it will probably open the findings, which are on the remote host inside the docker container. If I open dired from the tramp context, I will see files from that context, not files on my own machine. Context is the magic here. This level of integration is missing from VSCode. VSCode replicates part of these things, but things are not integrated. Want to ssh into a server? OK can do. Want to open files? OK here are your files from your own machine. It does not understand, that it should use the generic action of showing available files in the context of the opened SSH session. This might be a consequence of things being less coupled with keyboard workflow. When I use a mouse to click some menu items, it is not clear to VSCode in which opened tab/buffer that action should be performed. When I press a keyboard shortcut in Emacs, there will be a buffer (or mini buffer, or whatever) which has the focus and does not have to lose the focus, because I am not using the mouse to click outside of it. Things which are taken for granted in Emacs (all that integration and generic actions, which work anywhere) do not seem to exist in VSCode. Maybe most people are not even aware of how generic actions like opening a file could be integrated, because they have never seen it like it is in Emacs. On the other hand, VSCode might have a more fluent experience for when you do not want to do anything more complex than SSH into a server and might be speedier at those simpler workflows. There are probably well paid engineers at MS, who try to make things run smoothly when the shell is an SSH session on a remote server. I have not benchmarked this. Just a guess.
- kfajdsl 4y ago
  > Want to open files? OK here are your files from your own machine. It does not understand, that it should use the generic action of showing available files in the context of the opened SSH session. Are you sure? If I launch a remote session window and click open file/folder, it's on the remote (either SSH or docker for my workflows). VS Code runs a server on the remote with any plugins (including LSP servers) installed with it. This is as opposed to Emacs, which AFAIK does not have a server on the remote and instead interacts with the remote directly using SSH (or `docker exec`, etc). Note, you still need to have any LSP servers installed on the remote if you want that capability. I would argue that VS Code's remote editing experience feels more integrated than Emacs with TRAMP; I've had issues before where something is more difficult to do over TRAMP than locally, but I've never had that with VS Code. You're right though, "blows out of the water" is a stretch, I just have fights with TRAMP fresh in my head haha In terms of making editing on a remote seem just like editing locally, both VS Code and TRAMP are capable, I just find VS Code remote editing to be much more user friendly. It just works with little to no configuration.
alwillis 4y ago
Neovim. It is lighter weight than either Emacs or VS Code but can still have pretty much all the bells and whistles. Definitely cool if you prefer to live in a terminal. There are several GUIs for Neovim for various platforms [1]. [1]: https://github.com/neovim/neovim/wiki/Related-projects#gui https://github.com/neovim/neovim/wiki/Related-projects#gui

sokoloff 4y ago

> VS Code remote editing blows TRAMP out of the water I’ll have to try VSCode in this area, but Tramp seems pretty awesome to me so I’m trying to think how it could be blown out of the water.

kfajdsl 4y ago
In the "just works" department mainly, especially in regards to other packages playing nice with tramp.

ParetoOptimal 4y ago

> VS Code remote editing blows TRAMP out of the water One place emacs has a huge advantage is it doesn't use hardly any resources in the docker container. The vscode remote server instance uses a constant 15%-30% however. In real world terms this means a compile that takes 1 minute for me takes 2 minutes for my coworkers that use vs code. There are many potential confounding factors that could affect the performance discrepancy of course, but I think it's still useful given I can't think of many other plaform differences and that it's consistent amongst my coworkers.

kfajdsl 4y ago
This is true; not having that remote server has its pros and cons. VS Code is also just in general slower than Emacs haha. I'm surprised the difference is that much though!

zelphirkalt 4y ago

> VS Code remote editing blows TRAMP out of the water I think it is not that black & white. Recently I've used tramp to dial into a server via SSH and there into a docker container and directly edit files inside. I don't think VSCode can do the same inside a shell it starts. Sure it may be able to open an SSH shell and then from there you might be able to type in some docker exec command. But that is not the same as tramp into docker container on a remote host via SSH for the following reasons: When I use keyboard shortcuts from inside that tramp shell, Emacs understands, that it happens inside the tramp context and for example will only show me files inside that docker container, when I do a find-file. Should I decide to run an rgrep from that context, it will show me results in that context. If I click the findings of that rgrep, it will probably open the findings, which are on the remote host inside the docker container. If I open dired from the tramp context, I will see files from that context, not files on my own machine. Context is the magic here. This level of integration is missing from VSCode. VSCode replicates part of these things, but things are not integrated. Want to ssh into a server? OK can do. Want to open files? OK here are your files from your own machine. It does not understand, that it should use the generic action of showing available files in the context of the opened SSH session. This might be a consequence of things being less coupled with keyboard workflow. When I use a mouse to click some menu items, it is not clear to VSCode in which opened tab/buffer that action should be performed. When I press a keyboard shortcut in Emacs, there will be a buffer (or mini buffer, or whatever) which has the focus and does not have to lose the focus, because I am not using the mouse to click outside of it. Things which are taken for granted in Emacs (all that integration and generic actions, which work anywhere) do not seem to exist in VSCode. Maybe most people are not even aware of how generic actions like opening a file could be integrated, because they have never seen it like it is in Emacs. On the other hand, VSCode might have a more fluent experience for when you do not want to do anything more complex than SSH into a server and might be speedier at those simpler workflows. There are probably well paid engineers at MS, who try to make things run smoothly when the shell is an SSH session on a remote server. I have not benchmarked this. Just a guess.

kfajdsl 4y ago
> Want to open files? OK here are your files from your own machine. It does not understand, that it should use the generic action of showing available files in the context of the opened SSH session. Are you sure? If I launch a remote session window and click open file/folder, it's on the remote (either SSH or docker for my workflows). VS Code runs a server on the remote with any plugins (including LSP servers) installed with it. This is as opposed to Emacs, which AFAIK does not have a server on the remote and instead interacts with the remote directly using SSH (or `docker exec`, etc). Note, you still need to have any LSP servers installed on the remote if you want that capability. I would argue that VS Code's remote editing experience feels more integrated than Emacs with TRAMP; I've had issues before where something is more difficult to do over TRAMP than locally, but I've never had that with VS Code. You're right though, "blows out of the water" is a stretch, I just have fights with TRAMP fresh in my head haha In terms of making editing on a remote seem just like editing locally, both VS Code and TRAMP are capable, I just find VS Code remote editing to be much more user friendly. It just works with little to no configuration.

alwillis 4y ago

Neovim. It is lighter weight than either Emacs or VS Code but can still have pretty much all the bells and whistles. Definitely cool if you prefer to live in a terminal. There are several GUIs for Neovim for various platforms [1]. [1]: https://github.com/neovim/neovim/wiki/Related-projects#gui https://github.com/neovim/neovim/wiki/Related-projects#gui