I’ve seen this pop up a lot lately—someone who’s been using Emacs or Vim for years and then sees the “new cool” editor and says they’ll be switching to it.
I have the same question, since someone who’s used Emacs for that long would surely have “seen the light” already. Maybe they’re yak shaving with the config instead of getting work done? That’s one of the few valid complaints I can think of.
I used Emacs for a couple of decades but switched over to VS Code after a couple of days of playing with it. I love Emacs and the concept of infinite configurability. But as it turns out, I don't actually use most of that flexibility. It's more common that I'll install a package, tweak a couple of knobs, and get on with work.
Well, VS Code offers the equivalents of all the Emacs packages that I actually use, and they come with sane defaults. Once I've tweaked the Python module a little bit, I tend to ignore its other options and get back to editing code. And in that code editing environment, I honestly prefer VS Code. The key bindings feel like other modern apps (yay for using the same Mac shortcuts for moving around that every thing else uses). Menus (and their shortcuts) work as expected. I don't have Emacs's beautiful macros, but I do have multi-cursor editing which is beautiful in a different way. It's fast. It looks pretty, with nice easier-to-install themes and icon packages. Basically, VS Code does everything that I ask of Emacs, but in a modern package.
I still love Emacs. I had switched to Sublime Text at one point but came back to the 'Macs because ST wasn't good enough to win me over permanently. And I definitely still love the idea that I can rewrite all of Emacs to make it my own personal slice of editing heaven that is optimized for me and me alone. That's wonderful! But now that there's an excellent, MIT-licensed, well supported alternative that doesn't everything that I want in practice, I'm sold.
But if MS ever loses the plot and ruins VS Code, I'll be back on Emacs in a heartbeat.
VS Code does not come with magit... and that in and of itself is a great reason to use Emacs. (This is coming from a daily Vim user) There really is nothing like Magit even as a plugin for VSC. VSC's scm mode is what I'd consider "barely passible". You can do stuff with it, but it's tiny/ugly/not very friendly. And that GitLens plugin doesn't really help with staging files/hunks etc... it's more meta info about past commits.
That said, I've realized that I don't do that much SCM stuff inside my editor. It's nice to have a beautiful client, but I'm comfortable with the git commandline itself and found myself using it for the tricky stuff, even when I had Magit at my fingertips.
My main editor-integrated workflow involves switching branches, committing, pulling, and other routing stuff that VSC handles just fine. It's definitely no Magit, but it covers 95% of the stuff I do.
I used VSCode for a few years, but never found a way to work with code in semantic units vs. as text. And I like that no matter what language I'm working in, the experience is the same. VSCode plugin editors may or may not (read: wouldn't have) agreed on a set of conventions for working with code independent of the programming language.
I tried that, but it never worked as well for me as it did in Sublime Text, or more recently VS Code.
I get what you mean about Emacs's nearly universal code conventions, but that's an example of something I personally found to be more useful in theory than in practice. While I love the concept, 95% of the time I'm hacking around in Python. The rest of the time is a hodge-podge of shell scripts and the rare C snippet. Maybe a little SQL now and then, or perhaps some JavaScript. When I'm working in something that isn't my usual, I find myself spending much more time reading code than writing it, and in that context I don't get as much benefit from those conventions.
Of course this is all incredibly subjective. If you get a lot of benefit from that, awesome! I can definitely see the appeal. I just don't feel like it makes a whole lot of difference for me.
I admit that I have spent a lot of time adjusting Emacs to my preferences (by writing Emacs Lisp code that gets loaded automatically every time my Emacs starts). I am not particularly unhappy about that fact however and will probably spend a lot of time writing code that runs inside vscode if it becomes my daily driver.
Note that I use the graphical interface to Emacs and would've left Emacs many years ago if itworked only inside the terminal environment. I'm guessing you prefer to work in the terminal environment.
Many people don't realize it, but Emacs has been able to act somewhat like a native GTK+ app, a native Mac app or an native Windows app since the early 1990s. "somewhat": right clicking does something idiosyncratic (namely, if there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI; the standard behavior of course being to pop up a contextual menu, which by the way is what I adjusted my Emacs to do by writing about 100 lines of Emacs Lisp code) but left clicking moves the insertion point to the site of the click (the conventional behavior on Mac and Windows) and dragging the mouse does the conventional thing, too.
I like the "just the fact" nature of the terminal environment, but I also like pointing devices. Emacs and vscode (and Plan 9, but Plan 9 has problems that prevented me from ever spending much time there) constitute a happy middle ground between the terminal environment and the overly chaotic environments of Mac apps in general, Windows apps in general and the web. I have yet to see vscode's being used intensively (like Emacs is being used) for tasks other than programming, but would be delighted if vscode or maybe some platform derived from vscode were to start being used like that.
Maybe I will be the first one to write a really popular vscode extension designed for some purpose other than programming.
> f there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI
Emacs does that in X11 because that is (or at least was) the standard behavior for text selection in X11. Emacs is simply conforming to the environment it is running within.
Emacs's Mac (graphical) interface does that, too, which is not conforming to the environment it is running in.
And there is no user option for changing it to a contextual menu containing Cut, Copy, Paste, etc. (I changed it for myself by writing about 100 lines of Emacs Lisp.)
Emacs was taught to run graphically with X11 first, and presumably operates that way across platforms for a consistent interface irrespective of platform.
Even iTerm supports middle-click paste. Unix people are used to it.
I would guess that’s because IIRC, there’s no official support for Emacs to display native windows in Cocoa, and Emacs is simply using macOS’ X11 compatibility system.
If you could fix that behavior so that Emacs behaves more like a native Cocoa application, I see no reason that the Emacs maintainers should reject a patch. Emacs has, as far as I can tell, always strived to use as much of a native system’s interface and conventions as possible. Emacs is very big, so it might seem to be a self-contained world of its own, but it’s trying not to be too idiosyncratic.
>I would guess that’s because IIRC, there’s no official support for Emacs to display native windows in Cocoa
You would guess wrong.
(If you install an X server, you can run Emacs on X11 on a Mac, but if you do, the text looks radically different from the text in other Mac apps. ADDED. whereas if you run Emacs directly on Cocoa, the way most Emacs users on Mac do it excepting the ones running Emacs inside a terminal environment, the text looks exactly the same as the text in, e.g., Textmate or Terminal.app.)
Hmm. I would then assume that Emacs has rudimentary rendering support in Cocoa, but is otherwise treating it as a variant of X11, and not the fully different graphical system it presumably is. Emacs still has no full-fledged Cocoa integration. That is still only available in the Aquamacs fork, as far as I know: http://aquamacs.org/
This is true. I hope I did not give a contrary impression? I was, somewhat briefly, aware of some of the complexities of Emacs running under NeXTSTEP (not the text-only Emacs 18 included with NeXTSTEP, but proper Emacs 19 with NeXTSTEP windowing support), but that was (obviously) many years ago, and I don’t claim to remember any of it. And I was certainly not involved in implementing any of it.
It's on a different computer than the one I am using now, so it is going to take me at least a few hours to share it. I will make another reply to your comment when I have it.
Ultimately, VS Code just works. I have bounced between Emacs and VS Code as a long time (many years) Emacs user. Things break less often, the extensions are nice, the extension model of the editor is much more coherent, and JavaScript is just a language I find easier to work with. It is much easier to find JavaScript that already solves some problem I have if I am extending the editor. The Python support is good enough. The extensions are all fine. The integrated terminal is actually quite decent, whereas Emacs integrated terminals have never actually been very good in my opinion. Lots of little things. I still use emacs for some things, but generally... VS Code is also open source so I am not too worried about the longevity of the editor at this point. Those are some things off the top of my head.
Oddly I left vscode for emacs for Tramp. Tramp makes it possible for me to have autocomplete, remote repl, remote debugging out of the box (with the python layer plugins in spacemacs). sshfs + terminal never felt integrated and autocomplete doesn't work from the python environment in the remote machine. That was the moment I thought that the flexibility of emacs is hard to match with text editors having a plugin system. I wonder if something like tramp will ever be written into vscode.
I use emacs `-nw` within tmux, on iterm2/3 on mac. There are several terrible problems with this setup which I've never bothered to lose a weekend to trying to sort out (don't misunderstand me: I have lost weekends to some of these problems, and I'm running out of spare weekends).
mac pbcopy/paste into emacs does strange and horrible things. Mouse and scroll-wheel integration roughly doesn't work at all. The list is long.
I also use terminal tools a lot (data engineering), so the terminal itself (and hence tmux) is an important part of my toolset. Meaning, I can't abandon the terminal. Nor do I want to -- as others have said, I have RSI issues with touchpads and mouse-clicking. Spectacle on Mac (or any actual tiling window manager on linux desktops) helps with that, but if I never had to touch a mouse/trackball again in my life, that would be awesome.
As others have said, I mostly want to use an integrated editor and get on with my job, rather than go down a half-century old rabbit hole of reading SICP just to tweak some editor defaults. Again, don't misunderstand me: learning LISP changed my life, man. But that's not the same as "can I enable rainbow delimiters for protobuf" (As an aside, Little Schemer is a much gentler intro to LISP, and also awesome.)
And since I know we're a community of people who get distracted by the next shiny problem to solve: please don't focus on trying to fix the list of issues I'm describing. That's not the point (and I have no spare weekends).
>Mouse and scroll-wheel integration roughly doesn't work at all.
emacs, when started with the -nw flag, has nothing to do with mouse gestures. The terminal emulator (iterm in your case) sits between you and emacs and does not pass mouse gestures to emacs.
Actually, to be painfully precise, there is a convention, which iterm and emacs might or might not use, by which iterm could conceivably pass the location of single left clicks to the emacs process, but, e.g., mouse drag events and scroll-wheel events never get passed.
So for example when the users drags the mouse, then presses Command-C, `emacs -nw` has no way of knowing the user did that, and if anything got into the system clipboard, that is iterm's doing, not emacs's.
Might I suggest `open Emacs.app` rather than `emacs -nw`?
Except for a GNU or Emacs logo that can be suppressed by setting the variable inhibit-startup-screen to non-nil and except for a tool bar that can be suppressed by evalling `(tool-bar-mode -1)`, the result is indistinguishable from a terminal window to most Mac users, but has mouse and scroll-wheel integration.
To be precise, after `(server-start)` is evalled inside the Emacs.app process, whenever the command line `emacsclient <file name>` runs anywhere, inside or outside the Emacs.app process, the Emacs.app "visits" (opens) <file name>.
I am one of those people who talked about switching from emacs to VS Code. I ended up learning just enough to teach it to my daughter, then stuck with emacs for everything I do myself.
Now that I read about all these younger people switching to emacs I feel even less inclined to "modernize" even though VS Code does look like a nice programmable editor.
I have the same question, since someone who’s used Emacs for that long would surely have “seen the light” already. Maybe they’re yak shaving with the config instead of getting work done? That’s one of the few valid complaints I can think of.