I really like your “why should you try Emacs in 2021” list. It rings very true to my experience with emacs (and vim). Back when I used it more regularly, aside from any kool-aid I drank around the efficiency of keyboard-driven editing, if I’m being honest, the main motivation was simply that it was fun. Emacs was cool to me because I saw it as vintage, alternative, customizable, a component and expression of a hacker identity. It was an expression of programming-as-hobby as opposed to programming-as-profession. Of course I genuinely did enjoy the editing experience, and developing a healthy .emacs. I loved magit, projectile, helm, the clojure packages, etc. But I ended up in a place professionally where ultimately Emacs had no leverage over more specialized tools for what I was working on.
Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material.
Some people put it in terms of “it’s basically a Lisp machine environment”, and they’re not wrong (albeit it’s not a particularly good Lisp machine, I guess :-P).
I’ve been trying to get myself to use VS Code on and off for a few years now, as Emacs is not exactly thriving tech these days and I don’t suppose it’s going to get much better in the next fifteen years. Aside from muscle memory and weird UI choices (why in the world are we using three lines’ worth of screen estate to show the current file name and three icons!?), the fact that it doesn’t have the kind of introspection and interactivity Emacs has is what’s giving me the most headaches.
I want to automate some tedious code generation, or generate some test data? That’s five lines of Emacs Lisp, bind them to a key (I can do all of that in the scratch buffer) and there we go. As far as I can tell, if I want to achieve the same thing with VS Code I pretty much have to create a custom extension, which I then have to package and install. That’s… quite an involved process for a one-off function.
Emacs is a view of a better, alternate reality, where our computing environments were completely under our control. It makes a bunch of compromises to the world-as-it-exists, and has many hideous warts, because it’s old, but it’s the best computing environment widely available, by my metrics.
I have never used emacs (ok, I “used” it for about a month, ~20 years ago, but I never got the hang of it), but I use acme (from Plan 9). While acme couldn’t be further from emacs in terms of UI, UX, and philosophy, they are both equally far from “regular” editors like vscode and whatever. Once you have used an environment like this, all the “regular” editors seem equally crippled to you, equally not interesting, and equally missing the point of what’s important. Their differences become trivial.
I really like acme, too. By the time I got a chance to really play with Plan 9 I already knew Emacs and I was too far gone to the other side but I do wish Emacs played better with the outside world, the way acme does. For a while I actually tried to hack an acme-mode for Emacs that would allow Emacs to interact with the outside world the way acme does but it didn’t get too far. This was like ten years ago though, maybe things are better now.
IMHO, while the differences in UI are tremendous, the difference in philosophy, for lack of a better term, is not as deep. Acme is obviously more “outward”-oriented, in line with its Unix heritage, whereas Emacs is far more “inward”-oriented, partly because it comes from a different world, partly because it sought to re-create much of that different world under a different environment. But Emacs’ “internal” environment, while operating in terms of different abstractions than those of Unix (files, processes, pipes) into which Acme so seamlessly plugs, is remarkably similar to Acme’s.
For example, one of the things I like the most, and which I find myself using quite frequently, is an 8-line function that replaces an S-exp with its value. This allows me to write something like One hour from now it'll be (format-time-string "%H:%M" (seconds-to-time (time-add (current-time) 3600))) in a buffer, hit F12 at the end of the line, and get all the parentheses replaced with what they evaluate to, yielding One hour from now it'll be 01:10 in my buffer. This is basically Acme’s command execution, except it’s in terms of Emacs Lisp functions, not processes + some conventional commands like Cut, Snarf etc.. It’s… either more, or less powerful, depending on how much Emacs Lisp that does what you need you have around.
(I know it’s a silly example, it’s just the easiest concrete one I could come up with on the spot. Over time I used it for all sorts of things – e.g. when testing a bytecode VM, I could write something like test_payload = (bytecode-assemble "mov r8, r12"), hit F12, and get test_payload = [0xDE, 0xAD, 0xBE, 0xEF] or whatever)
But ultimately it still boils down to a text editor plus an environment from which to assemble a “text processing workbench”, except with different parts – Emacs has its own, Acme allows you to borrow them from the Unix environment. IMHO the latter approach is better. Lots of things, like real code completion and compiler integration support only landed in Emacs once it got reasonable support for borrowing tools from the outside.
As for VS Code… ironically, the thing that keeps me away from it the most is that honestly it’s just not a very good text editor :-D. Not only could I live without Emacs Lisp, I’d be extremely happy without Emacs Lisp, the language that embodies the simplicity of Common Lisp, the stunning feature set of Scheme, and the notorious openness and flexibility of RMS in one unholy Lispgoblin whose only redeeming feature is that at least it’s not Vimscript. Most of the Emacs Lisp code I write is one-off code that gets thrown away within minutes and I could do without it, I don’t really use much of Emacs’ renowned flexibility (in fact, last time I tried to, I yelled at rustic for like half a day). But in order to get things that I now think are basic, like easy back-and-forth navigation between arbitrary positions in different files, a kill ring, a save register, easily splitting/unsplitting views, oh and if possible a user interface that doesn’t light up and blink like a Christmas tree, I need to install a few dozen extensions, and that doesn’t look like an editor that’ll hold up for fifteen years…
No, that was sarcasm :-D. Emacs Lisp has a bunch of interesting pitfalls (e.g. for the longest time it only had dynamic scoping) and is not a very straightforward Lisp, much like Common Lisp. However, it’s feature set is fairly limited, much like Scheme (albeit IMHO in poorer taste, I’d rather write Scheme most of the time). Hence the “simplicity” of Common Lisp and the “stunning feature set” of Scheme :-).
I ended up in acme after 15+ years of emacs, partly out of curiosity after watching an rsc screencast and partly because I needed a break from my yearly cycle: juggle elisp packages to add features, tinker, tinker too much, declare configuration bankruptcy and repeat again.
I’m old enough that being able to quickly reuse existing tools is more valuable than the satisfaction of reimplementing them or integrating them into an editor. I do use other editors occasionally, and they are shiny and feel cool and certainly better at some tasks. But I end up back in the pale yellow expanse of tag bars and columns, because there’s another tool I need to interact with and I know I can get it done with files and pipes.
I sometimes think about how much time and effort goes in to editors and tooling integration, and wonder how we got to such a point.
This mirrors my own experiences with VS Code. It’s great, but it simple doesn’t have Emacs’ flexibility. The things that VS Code have envisioned people doing are great and easy to do, but if you try to do things besides that, you’re out of luck. VS Code does do a lot of things really well, but I keep coming back to Emacs (these days, Spacemacs) at the end of the day.
That’s five lines of Emacs Lisp, bind them to a key (I can do all of that in the scratch buffer) and there we go.
I found this line particularly intriguing as a vim user. Given that I also have some interest in learning common Lisp, I may just have to give emacs a try.
Is this not something you can do with vim? I’m not poking fun at it, I’m asking because it seems like a pretty small thing to change editors over. It may be far more useful to do this from the environment you already know.
I mean, I didn’t have some grand realization that Emacs is the best editor and thus attained eternal understanding of the Tao of text editors, it’s just that when I installed my first Linux distro, I installed it from one of those CDs that computer magazines came with and the CD was scratched or had sat too much in the sun or whatever, so it had a few corrupted packages that wouldn’t install. vim was one of them, emacs wasn’t, so I learned emacs (and for the longest time I didn’t really use it much – I still mostly used Windows for a couple of years, where I used UltraEdit). In 15+ years of seriously using Emacs, I don’t think I’ve ever used a feature my vim-using buddies frenemies couldn’t replicate, or vice-versa. Other than sane, non-modal editing, of course :-P.
I installed it from one of those CDs that computer magazines came with and the CD was scratched or had sat too much in the sun or whatever, so it had a few corrupted packages that wouldn’t install. vim was one of them, emacs wasn’t
I love this.
It’s very similar to my Emacs origin story. I was a dvorak typist (still am!) when I was in university and I knew I had to pick between vim and emacs. I looked at vim and it was like “just use hjkl; they are right there on the home row so it’s easy to press” and I was like “no they’re not!” and realized by process of elimination I might as well use emacs instead.
The reason I use vim is very similar to the reason you use emacs: it’s the first one we learned. In your case because your CD was damaged, in my case because my friend was using vim. There’s no harm in giving the other an honest try. I just don’t know when I’ll have the time.
I’ve spent 3 weeks trying to get started with emacs and could not even manage to edit file quickly, let alone doing stuff mu4e. I’ve been playing with Doom and Space without understanding anything. Your most makes me want to try again but, this time, by first buying a book and start very gradually. I appreciate your 5 steps to start with emacs.
I’m thorn. It looks really cool. It looks exactly what I want (everything in the command line). On the other hand, I feel I really appreciate the Unix philosophy “one tool-one function” and can reconcile the two views.
Emacs, in the beginning, is kind of strange to think about. The keybinds are all over the place, the people using Emacs seem to be these mystic wizards akin to the Greybeards in Skyrim, and the application itself has so much wording all over the place, it’s a lot to take in.
But in my experience, if you are/were a Vim user, is to simply use evil-mode, where I feel I get the best of both worlds of the two. I didn’t like using Spacemacs or Doom Emacs simply because the upstart was far more confusing for me. It was easier to add packages through the package.el library and play around with different modes and tweak things as I went. I added things like rainbow parentheses, Racket mode, neotree, and all these other tiny things that slowly built up to my current .emacs configuration.
There’s a whole lot of Emacs goodness that I probably don’t take advantage of, but the niceness of Emacs is too comfortable for me to want to leave. It’s easier to start small then gradually work your way up.
It’s been so long since I started with Vi(m) and Emacs I don’t quite remember how it was but I do recall that I really wanted to learn them and invested (and set aside) some time to do that.
I’m not sure that’s much of a recommendation for these tools though, these days.
However, my opinion was that much of what I was doing -and would be doing- was text based and I wanted a tool that was future-proof. I did not want to use different and every changing tools for editing, e-mail, news (Usenet), writing, etc.
I have not regretted investing the time.
(Vi(m) I accepted as it was and did not customize much, so I could use it wherever. Emacs (especially the default keybindings, which SUCK) is meant to be molded to your liking.)
I’ve also seen plenty of new editors rise and fall in the past 20 years - Komodo, TextMate, Sublime Text, Atom, etc.
Not sure why you would categorize Sublime Text as something that rose and fell. Recently had a major upgrade from 3 to 4, receives continuous updates & improvements and has superb LSP support. It’s very much alive and kicking.
You could offer the same defense of Komodo. But it’s really lost the momentum it had circa 2003. Things can decline without dying off completely, and I’d characterize all 4 of those editors as good examples of varying degrees of decline. Or “fall”, to use the author’s word.
They’re probably not as popular as they once were, but stuff like this is eternal. A certain kind of Windows-based grognard developer is probably still using SlickEdit/UltraEdit, while if they learned 20 years later they might have used Notepad++ (which is even now very popular with developers outside the Unix bubble we’re living in, IME).
I completely agree. And there’s BBEdit for the Mac grognards who pre-date Rails. jEdit, too, for those (mostly Windows folks) that came along between the UltraEdit heyday and Notepad++.
When I sit down with developers at non-tech companies I’d say I see more Notepad++ than VS Code.
(I find notepadqq to be a bit of a headscratcher but it is proof-by-existence that that style preference is not limited to the Windows-based crowd.)
I would say that TextMate, Sublime, Atom and Komodo have all dropped from being the default recommendation in certain spaces to various sized niches of happy (or happily indifferent) users. They’ve fallen, just not to their death.
I can’t articulate precisely why I find this space so interesting, but I think there’s a book or at least a series of blog posts here that would interest at least two or three people.
When I sit down with developers at non-tech companies I’d say I see more Notepad++ than VS Code.
I work heavily with these kinds of shops and Notepad++ tends to be their everything editor, but VS Code is rising in popularity, with lots of vendor-provided Eclipse too and sometimes IDEA. Rarely anything else, and I’ve never seen a Vim/Emacs user in these kinds of places. Hell, I’ve seen also-rans long-rans like TextPad in use more often by my kind of client.
Vim and Emacs are eternal if you go to university CS labs and startups (the frequent audience of Lobsters and especially HN) but non-existent everywhere else.
I would say that TextMate, Sublime, Atom and Komodo have all dropped from being the default recommendation in certain spaces to various sized niches of happy (or happily indifferent) users. They’ve fallen, just not to their death.
Yup. I sometimes wonder is Sublime/SlickEdit/etc can sustain, but they clearly must be if someone’s still buying the licenses.
I can’t articulate precisely why I find this space so interesting, but I think there’s a book or at least a series of blog posts here that would interest at least two or three people.
I am the exception that used both Vim and Emacs outside of school well before I was involved in University CS labs, and I’ve never worked at a proper startup.
That being said, I do use VS Code for writing C# for my job.
One of the things that trip me when I first tried emacs is what I wanted it to do too much without having any clue what was happening. I wanted it to replace by go IDE (GoLand), my JS and Rust tools (VS Code) and work perfectly with the language I was just learning (Elixir).
After a bunch of copy/paste and like 500 lines in init.el that I didn’t know what they where doing I obviously felt flat on my face.
Nowadays I’ve come back to it with more curiosity and less expectations. Got it working perfectly for beancount, got rid of the awkward (for me) hotkeys with evil, got the fonts and colors that I like, and now I’m free to explore and grow from here :-)
The rest of the tools are fine and I’m sure that emacs could replace them, but Idk how nor I need to know right now… I can just enjoy the experience!
If you are looking for something between Doom and vanilla, the author’s prelude starter kit is great. And if you use org-mode,
the sci-max kit has some really helpful utilities.
I personally can’t seem to feel at home adding on to any of the starter kits, but I’ve pulled in some things from both of these to my hot garbage of an ancient config mess. :)
I think doom is an incredible mix of out of box power, emacs customizability, and evil mode. Even as a power user, distributions ensure I don’t miss out on new features, as my dot files over time are likely to lag behind without a lot of attention.
Also recommending Doom Emacs. After 20 (25ish?) years of Emacs I switched to Doom Emacs so I could throw away a large part of my homegrown config and not having to maintain it anymore.
For me it does the same as the i3 window manager and the Fish shell: it has sensible defaults that I am mostly willing to accept to save time on config maintenance. (Ofcourse I still have my own customizations to these tools.)
His ErgoEmacs project is the single biggest boost to Emacs usability I’ve seen. It has an external maintainer now:
https://ergoemacs.github.io/
But it needs more work IMHO. Not being an Emacs expert, I can’t even get the Github version to install. I had to use Xah’s old version.
But this, I feel, is the way to win more users: to round off Emacs’ weird 1970s UI and bring it in line with basically every other editor in the last 25-30 years.
I agree. I think that there should be an ergo mode that is part of the default set of packages. It should make things as close as possible to what is expected for UIs these days. ctrl-xcv cut and paste, ctrl-z undo. ctlr-s for save. ctrl-f for a search. Probably some sort of region selection that isn’t mark and point.
It could probably detect if ctlr-x was followed by any key that would be bound to a command in normal emacs and put a warning in the mini buffer about it.
Install an additional binary where this mode is on by default. Call it emacspad or something.
Sounds good, although a whole new binary seems like overkill.
I think one thing that stood out to me in the ErgoEmacs docs on Github was that it said:
«
To enable emacs, add the following to your ~/.emacs or ~/.emacs.d/init.el file:
»
I am a new user. I don’t have either of these files. I don’t know which to use or how to tell.
Surely this is only relevant to existing Emacs users, who have such a config, and the sane default would be “this is on unless the user has an existing config file”…?
When I suggested this approach in a mailing-list discussion, the Emacs fans were apopletic and at least one of them said he was blocking me for my vile unreasonable attitude.
And yet, they wonder why more new users don’t adopt their editor. ¯_(ツ)_/¯
Problem 2: the instructions assume US English and don’t clearly describe how to configure anything else. I’d think a sane default was “if there is no existing config file, check what the OS regional settings are and use that.”
About
And
BEHOLD! My (Neo)Vim configuration.
neovim controlled with fennel; looks good :D
Pretty cool!
I really like your “why should you try Emacs in 2021” list. It rings very true to my experience with emacs (and vim). Back when I used it more regularly, aside from any kool-aid I drank around the efficiency of keyboard-driven editing, if I’m being honest, the main motivation was simply that it was fun. Emacs was cool to me because I saw it as vintage, alternative, customizable, a component and expression of a hacker identity. It was an expression of programming-as-hobby as opposed to programming-as-profession. Of course I genuinely did enjoy the editing experience, and developing a healthy
.emacs. I loved magit, projectile, helm, the clojure packages, etc. But I ended up in a place professionally where ultimately Emacs had no leverage over more specialized tools for what I was working on.Some people put it in terms of “it’s basically a Lisp machine environment”, and they’re not wrong (albeit it’s not a particularly good Lisp machine, I guess :-P).
I’ve been trying to get myself to use VS Code on and off for a few years now, as Emacs is not exactly thriving tech these days and I don’t suppose it’s going to get much better in the next fifteen years. Aside from muscle memory and weird UI choices (why in the world are we using three lines’ worth of screen estate to show the current file name and three icons!?), the fact that it doesn’t have the kind of introspection and interactivity Emacs has is what’s giving me the most headaches.
I want to automate some tedious code generation, or generate some test data? That’s five lines of Emacs Lisp, bind them to a key (I can do all of that in the scratch buffer) and there we go. As far as I can tell, if I want to achieve the same thing with VS Code I pretty much have to create a custom extension, which I then have to package and install. That’s… quite an involved process for a one-off function.
Emacs is a view of a better, alternate reality, where our computing environments were completely under our control. It makes a bunch of compromises to the world-as-it-exists, and has many hideous warts, because it’s old, but it’s the best computing environment widely available, by my metrics.
I have never used emacs (ok, I “used” it for about a month, ~20 years ago, but I never got the hang of it), but I use acme (from Plan 9). While acme couldn’t be further from emacs in terms of UI, UX, and philosophy, they are both equally far from “regular” editors like vscode and whatever. Once you have used an environment like this, all the “regular” editors seem equally crippled to you, equally not interesting, and equally missing the point of what’s important. Their differences become trivial.
I really like acme, too. By the time I got a chance to really play with Plan 9 I already knew Emacs and I was too far gone to the other side but I do wish Emacs played better with the outside world, the way acme does. For a while I actually tried to hack an
acme-modefor Emacs that would allow Emacs to interact with the outside world the way acme does but it didn’t get too far. This was like ten years ago though, maybe things are better now.IMHO, while the differences in UI are tremendous, the difference in philosophy, for lack of a better term, is not as deep. Acme is obviously more “outward”-oriented, in line with its Unix heritage, whereas Emacs is far more “inward”-oriented, partly because it comes from a different world, partly because it sought to re-create much of that different world under a different environment. But Emacs’ “internal” environment, while operating in terms of different abstractions than those of Unix (files, processes, pipes) into which Acme so seamlessly plugs, is remarkably similar to Acme’s.
For example, one of the things I like the most, and which I find myself using quite frequently, is an 8-line function that replaces an S-exp with its value. This allows me to write something like
One hour from now it'll be (format-time-string "%H:%M" (seconds-to-time (time-add (current-time) 3600)))in a buffer, hit F12 at the end of the line, and get all the parentheses replaced with what they evaluate to, yieldingOne hour from now it'll be 01:10in my buffer. This is basically Acme’s command execution, except it’s in terms of Emacs Lisp functions, not processes + some conventional commands like Cut, Snarf etc.. It’s… either more, or less powerful, depending on how much Emacs Lisp that does what you need you have around.(I know it’s a silly example, it’s just the easiest concrete one I could come up with on the spot. Over time I used it for all sorts of things – e.g. when testing a bytecode VM, I could write something like
test_payload = (bytecode-assemble "mov r8, r12"), hit F12, and gettest_payload = [0xDE, 0xAD, 0xBE, 0xEF]or whatever)But ultimately it still boils down to a text editor plus an environment from which to assemble a “text processing workbench”, except with different parts – Emacs has its own, Acme allows you to borrow them from the Unix environment. IMHO the latter approach is better. Lots of things, like real code completion and compiler integration support only landed in Emacs once it got reasonable support for borrowing tools from the outside.
As for VS Code… ironically, the thing that keeps me away from it the most is that honestly it’s just not a very good text editor :-D. Not only could I live without Emacs Lisp, I’d be extremely happy without Emacs Lisp, the language that embodies the simplicity of Common Lisp, the stunning feature set of Scheme, and the notorious openness and flexibility of RMS in one unholy Lispgoblin whose only redeeming feature is that at least it’s not Vimscript. Most of the Emacs Lisp code I write is one-off code that gets thrown away within minutes and I could do without it, I don’t really use much of Emacs’ renowned flexibility (in fact, last time I tried to, I yelled at rustic for like half a day). But in order to get things that I now think are basic, like easy back-and-forth navigation between arbitrary positions in different files, a kill ring, a save register, easily splitting/unsplitting views, oh and if possible a user interface that doesn’t light up and blink like a Christmas tree, I need to install a few dozen extensions, and that doesn’t look like an editor that’ll hold up for fifteen years…
Did you mean to say “the simplicity of Scheme and the stunning feature set of Common Lisp” instead?
No, that was sarcasm :-D. Emacs Lisp has a bunch of interesting pitfalls (e.g. for the longest time it only had dynamic scoping) and is not a very straightforward Lisp, much like Common Lisp. However, it’s feature set is fairly limited, much like Scheme (albeit IMHO in poorer taste, I’d rather write Scheme most of the time). Hence the “simplicity” of Common Lisp and the “stunning feature set” of Scheme :-).
😂 Alright!!
The inward/outward comparison is apt.
I ended up in acme after 15+ years of emacs, partly out of curiosity after watching an rsc screencast and partly because I needed a break from my yearly cycle: juggle elisp packages to add features, tinker, tinker too much, declare configuration bankruptcy and repeat again.
I’m old enough that being able to quickly reuse existing tools is more valuable than the satisfaction of reimplementing them or integrating them into an editor. I do use other editors occasionally, and they are shiny and feel cool and certainly better at some tasks. But I end up back in the pale yellow expanse of tag bars and columns, because there’s another tool I need to interact with and I know I can get it done with files and pipes.
I sometimes think about how much time and effort goes in to editors and tooling integration, and wonder how we got to such a point.
The “outward” vs. “inward” distinction WRT Bell Labs/Unix/C and PARC/Lisp/Smalltalk is a fascinating one. Reminds me of Rob Pike’s experience report after visiting PARC: https://commandcenter.blogspot.com/2019/01/notes-from-1984-trip-to-xerox-parc.html.
This mirrors my own experiences with VS Code. It’s great, but it simple doesn’t have Emacs’ flexibility. The things that VS Code have envisioned people doing are great and easy to do, but if you try to do things besides that, you’re out of luck. VS Code does do a lot of things really well, but I keep coming back to Emacs (these days, Spacemacs) at the end of the day.
I found this line particularly intriguing as a vim user. Given that I also have some interest in learning common Lisp, I may just have to give emacs a try.
Is this not something you can do with vim? I’m not poking fun at it, I’m asking because it seems like a pretty small thing to change editors over. It may be far more useful to do this from the environment you already know.
I mean, I didn’t have some grand realization that Emacs is the best editor and thus attained eternal understanding of the Tao of text editors, it’s just that when I installed my first Linux distro, I installed it from one of those CDs that computer magazines came with and the CD was scratched or had sat too much in the sun or whatever, so it had a few corrupted packages that wouldn’t install. vim was one of them, emacs wasn’t, so I learned emacs (and for the longest time I didn’t really use it much – I still mostly used Windows for a couple of years, where I used UltraEdit). In 15+ years of seriously using Emacs, I don’t think I’ve ever used a feature my vim-using
buddiesfrenemies couldn’t replicate, or vice-versa. Other than sane, non-modal editing, of course :-P.I love this.
It’s very similar to my Emacs origin story. I was a dvorak typist (still am!) when I was in university and I knew I had to pick between vim and emacs. I looked at vim and it was like “just use hjkl; they are right there on the home row so it’s easy to press” and I was like “no they’re not!” and realized by process of elimination I might as well use emacs instead.
The reason I use vim is very similar to the reason you use emacs: it’s the first one we learned. In your case because your CD was damaged, in my case because my friend was using vim. There’s no harm in giving the other an honest try. I just don’t know when I’ll have the time.
Oh. Well in that case, have fun with emacs! The tentacle fingers are gonna come in super handy once you grow them.
(They did tell you about the tentacle fingers right?)
I’ve spent 3 weeks trying to get started with emacs and could not even manage to edit file quickly, let alone doing stuff mu4e. I’ve been playing with Doom and Space without understanding anything. Your most makes me want to try again but, this time, by first buying a book and start very gradually. I appreciate your 5 steps to start with emacs.
I’m thorn. It looks really cool. It looks exactly what I want (everything in the command line). On the other hand, I feel I really appreciate the Unix philosophy “one tool-one function” and can reconcile the two views.
Emacs, in the beginning, is kind of strange to think about. The keybinds are all over the place, the people using Emacs seem to be these mystic wizards akin to the Greybeards in Skyrim, and the application itself has so much wording all over the place, it’s a lot to take in.
But in my experience, if you are/were a Vim user, is to simply use
evil-mode, where I feel I get the best of both worlds of the two. I didn’t like using Spacemacs or Doom Emacs simply because the upstart was far more confusing for me. It was easier to add packages through thepackage.ellibrary and play around with different modes and tweak things as I went. I added things like rainbow parentheses, Racket mode, neotree, and all these other tiny things that slowly built up to my current.emacsconfiguration.There’s a whole lot of Emacs goodness that I probably don’t take advantage of, but the niceness of Emacs is too comfortable for me to want to leave. It’s easier to start small then gradually work your way up.
It’s been so long since I started with Vi(m) and Emacs I don’t quite remember how it was but I do recall that I really wanted to learn them and invested (and set aside) some time to do that.
I’m not sure that’s much of a recommendation for these tools though, these days.
However, my opinion was that much of what I was doing -and would be doing- was text based and I wanted a tool that was future-proof. I did not want to use different and every changing tools for editing, e-mail, news (Usenet), writing, etc.
I have not regretted investing the time.
(Vi(m) I accepted as it was and did not customize much, so I could use it wherever. Emacs (especially the default keybindings, which SUCK) is meant to be molded to your liking.)
Not sure why you would categorize Sublime Text as something that rose and fell. Recently had a major upgrade from 3 to 4, receives continuous updates & improvements and has superb LSP support. It’s very much alive and kicking.
You could offer the same defense of Komodo. But it’s really lost the momentum it had circa 2003. Things can decline without dying off completely, and I’d characterize all 4 of those editors as good examples of varying degrees of decline. Or “fall”, to use the author’s word.
They’re probably not as popular as they once were, but stuff like this is eternal. A certain kind of Windows-based grognard developer is probably still using SlickEdit/UltraEdit, while if they learned 20 years later they might have used Notepad++ (which is even now very popular with developers outside the Unix bubble we’re living in, IME).
I completely agree. And there’s BBEdit for the Mac grognards who pre-date Rails. jEdit, too, for those (mostly Windows folks) that came along between the UltraEdit heyday and Notepad++.
When I sit down with developers at non-tech companies I’d say I see more Notepad++ than VS Code.
(I find notepadqq to be a bit of a headscratcher but it is proof-by-existence that that style preference is not limited to the Windows-based crowd.)
I would say that TextMate, Sublime, Atom and Komodo have all dropped from being the default recommendation in certain spaces to various sized niches of happy (or happily indifferent) users. They’ve fallen, just not to their death.
I can’t articulate precisely why I find this space so interesting, but I think there’s a book or at least a series of blog posts here that would interest at least two or three people.
I work heavily with these kinds of shops and Notepad++ tends to be their everything editor, but VS Code is rising in popularity, with lots of vendor-provided Eclipse too and sometimes IDEA. Rarely anything else, and I’ve never seen a Vim/Emacs user in these kinds of places. Hell, I’ve seen also-rans long-rans like TextPad in use more often by my kind of client.
Vim and Emacs are eternal if you go to university CS labs and startups (the frequent audience of Lobsters and especially HN) but non-existent everywhere else.
Yup. I sometimes wonder is Sublime/SlickEdit/etc can sustain, but they clearly must be if someone’s still buying the licenses.
I would love it! I think a lot about this
I am the exception that used both Vim and Emacs outside of school well before I was involved in University CS labs, and I’ve never worked at a proper startup.
That being said, I do use VS Code for writing C# for my job.
One of the things that trip me when I first tried emacs is what I wanted it to do too much without having any clue what was happening. I wanted it to replace by go IDE (GoLand), my JS and Rust tools (VS Code) and work perfectly with the language I was just learning (Elixir).
After a bunch of copy/paste and like 500 lines in
init.elthat I didn’t know what they where doing I obviously felt flat on my face.Nowadays I’ve come back to it with more curiosity and less expectations. Got it working perfectly for beancount, got rid of the awkward (for me) hotkeys with evil, got the fonts and colors that I like, and now I’m free to explore and grow from here :-)
The rest of the tools are fine and I’m sure that emacs could replace them, but Idk how nor I need to know right now… I can just enjoy the experience!
Glad to hear it’s now working for you.
For those wanting to start, I suggest either:
The only config I’d recommend from the beginning is
(fido-mode), https://www.gnu.org/software/emacs/manual/html_node/emacs/Icomplete.html .If you are looking for something between Doom and vanilla, the author’s prelude starter kit is great. And if you use org-mode, the sci-max kit has some really helpful utilities.
I personally can’t seem to feel at home adding on to any of the starter kits, but I’ve pulled in some things from both of these to my hot garbage of an ancient config mess. :)
I think doom is an incredible mix of out of box power, emacs customizability, and evil mode. Even as a power user, distributions ensure I don’t miss out on new features, as my dot files over time are likely to lag behind without a lot of attention.
Also recommending Doom Emacs. After 20 (25ish?) years of Emacs I switched to Doom Emacs so I could throw away a large part of my homegrown config and not having to maintain it anymore.
For me it does the same as the i3 window manager and the Fish shell: it has sensible defaults that I am mostly willing to accept to save time on config maintenance. (Ofcourse I still have my own customizations to these tools.)
Same, as a long-time Emacs greybeard. I switched to Doom and got rid of a lot of garbage that I had accumulated over the years.
Xah Lee is eccentric to say the least, but I think he’s right about the need for Emacs modernization: http://xahlee.info/emacs/emacs/emacs_modernization.html
His ErgoEmacs project is the single biggest boost to Emacs usability I’ve seen. It has an external maintainer now: https://ergoemacs.github.io/
But it needs more work IMHO. Not being an Emacs expert, I can’t even get the Github version to install. I had to use Xah’s old version.
But this, I feel, is the way to win more users: to round off Emacs’ weird 1970s UI and bring it in line with basically every other editor in the last 25-30 years.
I agree. I think that there should be an ergo mode that is part of the default set of packages. It should make things as close as possible to what is expected for UIs these days. ctrl-xcv cut and paste, ctrl-z undo. ctlr-s for save. ctrl-f for a search. Probably some sort of region selection that isn’t mark and point.
It could probably detect if ctlr-x was followed by any key that would be bound to a command in normal emacs and put a warning in the mini buffer about it.
Install an additional binary where this mode is on by default. Call it emacspad or something.
Sounds good, although a whole new binary seems like overkill.
I think one thing that stood out to me in the ErgoEmacs docs on Github was that it said:
« To enable emacs, add the following to your ~/.emacs or ~/.emacs.d/init.el file: »
I am a new user. I don’t have either of these files. I don’t know which to use or how to tell.
Surely this is only relevant to existing Emacs users, who have such a config, and the sane default would be “this is on unless the user has an existing config file”…?
When I suggested this approach in a mailing-list discussion, the Emacs fans were apopletic and at least one of them said he was blocking me for my vile unreasonable attitude.
And yet, they wonder why more new users don’t adopt their editor. ¯_(ツ)_/¯
Problem 2: the instructions assume US English and don’t clearly describe how to configure anything else. I’d think a sane default was “if there is no existing config file, check what the OS regional settings are and use that.”