4 ms·

I'm a daily Emacs user, and happily use a 100 line init.el, mostly composed of "enable this mode". Emacs supports customization needs to the nth degree, but I'

I'm a daily Emacs user, and happily use a 100 line init.el, mostly composed of "enable this mode". Emacs supports customization needs to the nth degree, but I've found that this is a false economyy. I agree Emacs needs to be easier to get started with.

deworms 5y ago
You would probably be more productive in VS Code with an empty config.
- underatree 5y ago
  I think I would be more productive with VS Code too. But productivity isn't my only goal. I want to give back to the community: Emacs is introspectable enough that it allows me to easily contribute. I want to explore a different UI paradigm, which blurs the line between user and developer. I want to support a grassroots developed editor.
- rich_sasha 5y ago
  Emacs fits so nicely into my workflow. I can use it, feature-rich, from terminal, within tmux, and easily switching from the editor (where I write code) to other terminal panes (where I run the code). I can also use Emacs without any mouse input at all, have a rich set of keyboard shortcuts, and where I find myself doing something repetitive, I can easily automate it. While I'm at it, I can use the very same environment for a ton of other things - note-taking, editing more file types than I could care about etc. I can see that with different priorities, perhaps VS Code might be a better fit. But does it work in the terminal? Can I edit LaTeX and have equations rendered in-place? Can I easily switch layouts from having 3/4 panes of code and nothing else on the screen, to having various other bits around? Does C&P trivially support multiple "buffers" (registers in Emacs lingo; can copy & paste persistently to different places). Can I easily record rich keyboard macros - ones that, dunno, search second and third word on a line, replace first instance of second word with third word, then return to the starting point? I suspect the answer is yes to some of these questions, but no to most. And this is barely scratching the surface of what Emacs can do.
- 2pEXgD0fZ5cF 5y ago
  Can you elaborate with examples from both emacs and VSCode on why you believe that to be the case?
- BeetleB 5y ago
  > You would probably be more productive in VS Code with an empty config. Org mode is the main productivity multiplier. How do I do that in VS Code? Any time I read a comment where VSCode is the obvious alternative to Emacs, it's a clear sign the commenter knows little of Emacs. Take a look at last year's EmacsConf and count how many of the talks are about SW development (hint - minority). A very large number of Emacs users do not use it for SW development, and stating they'd be more productive in VS Code is simply false.
  - bmitc 5y ago
    I took a look at the EmacsConf talks and didn't see anything in particular that stood out. Mind pointing something out? At the end of the day, Emacs and VSCode are extensible environments and editors, so there's gonna be a lot of overlap and some fringe cases that are only possible on either one. But VSCode is definitely the more immediate of the two. I can install VSCode, sign in with my GitHub account, and immediately have my exact same environment as on any other machine. Any change I make to my environment, such as keybindings or installed extensions gets synced to other installations. I can remote into other computers and again have my same environment, developing as if I was on that computer itself. If I see a colleague with a certain behavior, all I usually have to do with VSCode is ask what extension it is, install it, and then I get the same behavior without any configuration (with Emacs, everyone has their own little custom environment). I don't ever need to be writing Emacs Lisp just to use the environment as I would expect to. You simply cannot do all of this with Emacs with the same usability and immediacy. And this alone is why I use VSCode. I have tried getting into Emacs. At one point, I was on Windows and needed to run MIT Scheme, which doesn't really work on Windows, so I installed and ran MIT Scheme on Windows Subsystem for Linux (WSL). Through some configuration of my .emacs file I was able to get things up and running by using Emacs on Windows and then calling into WSL and Scheme (this is before the days of official GUI support in WSL). It didn't really work in the end, despite all the hackery, one reason being Emacs' terminal is its own little custom thing. So I install VSCode, install the Remote - SSH extension, and I was off and running within minutes developing in a Windows GUI with code running on Linux, as if I was just on the Linux machine. So I never looked back. Any experiment of mine for Emacs meant I spent all this time trying to configure the editor to do what I'd expect rather than doing what I actually wanted to do. With VSCode, I have found that I rarely spend time needing to bend it to my will. It basically does what I need, and if not, there's extensions or simple configurations that accomplish it. I'm almost always working in VSCode and not working on VSCode. > Any time I read a comment where VSCode is the obvious alternative to Emacs, it's a clear sign the commenter knows little of Emacs. This is also why people stay away from Emacs.

deworms 5y ago

You would probably be more productive in VS Code with an empty config.

underatree 5y ago
I think I would be more productive with VS Code too. But productivity isn't my only goal. I want to give back to the community: Emacs is introspectable enough that it allows me to easily contribute. I want to explore a different UI paradigm, which blurs the line between user and developer. I want to support a grassroots developed editor.
rich_sasha 5y ago
Emacs fits so nicely into my workflow. I can use it, feature-rich, from terminal, within tmux, and easily switching from the editor (where I write code) to other terminal panes (where I run the code). I can also use Emacs without any mouse input at all, have a rich set of keyboard shortcuts, and where I find myself doing something repetitive, I can easily automate it. While I'm at it, I can use the very same environment for a ton of other things - note-taking, editing more file types than I could care about etc. I can see that with different priorities, perhaps VS Code might be a better fit. But does it work in the terminal? Can I edit LaTeX and have equations rendered in-place? Can I easily switch layouts from having 3/4 panes of code and nothing else on the screen, to having various other bits around? Does C&P trivially support multiple "buffers" (registers in Emacs lingo; can copy & paste persistently to different places). Can I easily record rich keyboard macros - ones that, dunno, search second and third word on a line, replace first instance of second word with third word, then return to the starting point? I suspect the answer is yes to some of these questions, but no to most. And this is barely scratching the surface of what Emacs can do.
2pEXgD0fZ5cF 5y ago
Can you elaborate with examples from both emacs and VSCode on why you believe that to be the case?
BeetleB 5y ago
> You would probably be more productive in VS Code with an empty config. Org mode is the main productivity multiplier. How do I do that in VS Code? Any time I read a comment where VSCode is the obvious alternative to Emacs, it's a clear sign the commenter knows little of Emacs. Take a look at last year's EmacsConf and count how many of the talks are about SW development (hint - minority). A very large number of Emacs users do not use it for SW development, and stating they'd be more productive in VS Code is simply false.
- bmitc 5y ago
  I took a look at the EmacsConf talks and didn't see anything in particular that stood out. Mind pointing something out? At the end of the day, Emacs and VSCode are extensible environments and editors, so there's gonna be a lot of overlap and some fringe cases that are only possible on either one. But VSCode is definitely the more immediate of the two. I can install VSCode, sign in with my GitHub account, and immediately have my exact same environment as on any other machine. Any change I make to my environment, such as keybindings or installed extensions gets synced to other installations. I can remote into other computers and again have my same environment, developing as if I was on that computer itself. If I see a colleague with a certain behavior, all I usually have to do with VSCode is ask what extension it is, install it, and then I get the same behavior without any configuration (with Emacs, everyone has their own little custom environment). I don't ever need to be writing Emacs Lisp just to use the environment as I would expect to. You simply cannot do all of this with Emacs with the same usability and immediacy. And this alone is why I use VSCode. I have tried getting into Emacs. At one point, I was on Windows and needed to run MIT Scheme, which doesn't really work on Windows, so I installed and ran MIT Scheme on Windows Subsystem for Linux (WSL). Through some configuration of my .emacs file I was able to get things up and running by using Emacs on Windows and then calling into WSL and Scheme (this is before the days of official GUI support in WSL). It didn't really work in the end, despite all the hackery, one reason being Emacs' terminal is its own little custom thing. So I install VSCode, install the Remote - SSH extension, and I was off and running within minutes developing in a Windows GUI with code running on Linux, as if I was just on the Linux machine. So I never looked back. Any experiment of mine for Emacs meant I spent all this time trying to configure the editor to do what I'd expect rather than doing what I actually wanted to do. With VSCode, I have found that I rarely spend time needing to bend it to my will. It basically does what I need, and if not, there's extensions or simple configurations that accomplish it. I'm almost always working in VSCode and not working on VSCode. > Any time I read a comment where VSCode is the obvious alternative to Emacs, it's a clear sign the commenter knows little of Emacs. This is also why people stay away from Emacs.