I’ve been using Emacs for ~15 years right now, but I don’t recommend it for the last few.
I love it, it’s great, and as many others, I tried to move out of it but there was something I couldn’t do I KNEW I could get in Emacs and it frustrated me so much I kept going back.
But I don’t think it brings a lot of added value. There are many very very powerful IDEs and editors which offer out of the box great UX and feature discoverability. Hell, probably if IntelliJ toolset would allow me to customize it deeper with Lua/Lisp/JS/whatever I’d probably switch in a jiffy.
I compare Emacs to vinyls or paper books. It requires investment, in many cases it is worse than competition and requires more energy to just be on par. But it is absolutely lovable. Vinyl record comparison - they are expensive, heavy, require a lot of maintenance but for specific type of people it makes their heart skip a beat when they take it from the sleeve.
That’s why people are constantly talking about their Emacs. Same with vim or nvim. I rarely hear people talking with excitement about WebStorm or VS code.
So yeah, if you’re not into it just keep in mind that like some freak who spend their weekend on polishing rims of dream come true 1959 Fiat 500, some of us spend their time with Emacs.
Don’t get bullied into it, don’t get FOMO about it, but please don’t spoil our fun.
I switched from VSCode to Doom Emacs with very little of my own customization (doing TS, Scala, Rust mostly) a few years ago. There is not one thing of VSCode that I miss, and I enjoy some of the most powerful features like wgrep & all, and a great vim emulation layer (the one I had in VSCode sucked).
I agree. Emacs out-of-the-box is terrible, but my Doom Emacs config is all 50 lines of code. For that I get:
- IDE-like features via LSP
- The best git porcelain out there: magit. Even when I'm not using emacs, I come back to magit for code-browsing (recursive blame) and staging hunks.
- Emacs/vim's fantastic buffer/window concept, where open files are not owned by their windows. I miss this whenever I use anything else.
- project support to quickly grep across all files or jump to files
- Very mature vi keybindings, with their infinite composability
I still sometimes find that it's either too rigid or too manual at certain things, but I could say the same for CLion and VSCode. I still come back to CLion for its refactoring tool, the 3-way merge window and the debugger integration.
It is a bit messy though. It's very well done for what it is, but it's cobbled together from many disparate components. It seems that it should be possible to create the same type of experience from a simpler, more coherent system. I rarely update the base system, but when I do, I've occasionally had to google for some exotic elisp error and add a fix here or there.
I guess I need to experiment with this. I'm fairly conservative when it comes to experimenting with files since I find it always ends up triggering .swp file recoveries, which is not just annoying[1], but has also resulted in me accidently losing work before.
[1] Why can't we just delete the extra file after we recovered the .swp!
Since reading your comment, I have gotten very excited about Doom Emacs in the last 45 minutes.
But, now I realize this is a very powerful configuration of Emacs if and only if you prefer using the VI keybindings.
It looks like spacemacs is that as well.
I actually enjoy Emacs keybindings, and would like to find something as polished and supported as Doom, but without using VI keybindings.
Does anyone know where I should look for that?
Or, can I revert to emacs keybindings in Doom and use the rest of the amazing features? I'm concerned I might be swimming against a tsunami if I try to do that and would be better off finding another project.
Alternative opinion that you completely didn't ask for: I wouldn't bother with Doom, or any of the other pre-packaged Emacs distributions. If you like the default Emacs bindings, I would suggest just... using Emacs.
Unconfigured Emacs is a bit clunky, but you'll understand it a lot better if you configure it yourself. Also, just in my opinion, there are better options than the packages supplied by Doom.
My suggestion is to set up Emacs with use-package for package configuration (this will be in Emacs 29 anyway), and then you can easily play around with different package combinations.
I'd add a nice-looking theme first of all, then try adding the following modern packages, one at a time. Play around with them a bit before adding another so you know what they do.
As mentioned, you can disable evil mode in spacemacs or doom.
There's also prelude which doesn't include evil by default. Not quite as fully featured as doom/spacemacs, but it's a good place to start.
All that said, you could just set it up from scratch. Now that lsp-mode and dap-mode are things, you can setup a fully featured IDE in not very much config at all. I have everything in my init.el and setting up projectile, lsp-mode and dap-mode which is like 85% of what you need for a fully featured IDE. That bit is only about 30 lines of config. Throw in flycheck, company-mode, hydra for keybindings. maybe treemacs for a project view.. a few hundred other lines to make it not all look like trash....
On second thought, it's kind of a pain in the ass. Just use clion or vscode or something.
Can't I beg you to share your init.el? I want LSP and the other stuff but Doom even when turning off evil mode seems to far away from the emacs I'm familiar with.
While Doom defaults to Vi bindings with evil mode (and has awesome defaults to use evil mode almost for all modules) I don't think it's mandatory at all and you should be able to enjoy it without evil (I haven't tried but after all, non-evil key bindings are the default on Emacs :) )
I had the same realization...so I took some bits of doomemacs/spacemacs and incorporated it into my personal emacs configuration. I am not great at maintaining my config or writing elisp in general, but feel free to reference my config if you wanted to take a stab at creating a doomemacs-like experience with your own configuration choices:
Disclaimer: This config is a bit perpetually dusty at this point, so I wouldn't copy it verbatim but instead use it as inspiration for some packages that might be worth looking into. JFYI anything that is from Marmelade might be worth avoiding as I suspect it is unmaintained given it's SSL cert expired in 2018. I just haven't gotten around to removing it from my config.
Spacemacs on initial start-up, it will prompt you to choose either evil mode (vi) or holy mode (standard emacs) keybindings. Before I went to vanilla emacs, I was a spacemacs user using the 'holy mode.'
Same. I was using intellij, then vscode the ten years before I switched to doom. I tried a lot of other editors and IDEs, but emacs was the only one with good vim integration. From all editors I tried, it was also the only one with good plugin interoperability. In emacs plugins are often build up on the interfaces of other plugins. In vscode plugins tend to be encapsulated, competing units which often do not play well together. I also find it much easier to customize emacs to my needs, because the interfaces of both the system and the plugins are mostly well documented.
Emacs has a high barrier of entry though. I think it would be difficult for a novice to get a good IDE experience from emacs, even with doom.
> It requires investment, in many cases it is worse than competition and requires more energy to just be on par.
One way to think of it is any tool requires some investment. The big difference with Emacs is it has always been around and always will be around, so you are continuously building upon that investment. Contrast that more modern tools. The learning curve is nowhere near as severe to start out, yet one is far less likely to learn how to use it so the same depth in the long term since it is far less likely to exist for the long term.
I've been using Emacs for 25 years, and I use a stock install and I never even touch the .emacs file.
It's just a text editor. For many tasks it has better usability than the competition. This is why I use it. (Not for everything, though, and that's okay.)
I'd guess most people are like me. Configuring text editors is not our hobby.
> There's a full Lisp implementation available in there.
Okay? Neovim and Lite XL ship with full Lua implementations. VSCode ships with a full JS implementation.
Being scriptable is not unique to Emacs. Though I do think the combination of
- big ecosystem (missing for Lite)
- scripting freedom (missing for VSC, iirc its plugin APIs are kinda limiting)
- GUI (neovim)
is pretty much unique.
A lot of other editors are also extensible, either via scripting or dynamically linking native code.
The only reason Org is unique to Emacs is that it's "too large to clone", i.e. it'd be a lot of work. I think a lot of editors could provide the same features with a plugin, given sufficient effort.
Most people get a car in order to drive from point A to point B. Not everyone puts a bra, rear-spoiler, fancy wheels, and other customizations on their car. I imagine the people who do those things also wonder why other people don't.
As a former elisp package maintainer and emacs bigot ...
... I really just use it as an editor/IDE these days, and couldn't be happier.
Emacs is how I learned LISP which forever transformed me as a programmer and I'm grateful. But let's be clear WHY I was doing that: it was horrible as an IDE at the time and I needed it to do the thing.
Now, with elpa, great themes, solid modes for every major language, magit etc, it just works. I customize ... via customization.
I still have my .emacs (dating myself there) and a few nifty functions I wrote. I maintain a programming language, so pact-mode is still there. The ugly truth there is that it's actually easier to write integrations (for a LISP-like no less!) for VS Code than write a major mode.
I miss hacking on emacs but I'm more productive for it.
I find it fun to find random poop.cpp~ from 5 years ago in some random place on the filesystem. It's like discovering buried treasure. Who knows what's in there? Could be anything!
My first, very brief, foray into Emacs was at the suggestion of a friend back in, oh, '91-92. He raved about the buffers and the shell windows. Well, I couldn't run my 4GL programs in the shell windows, since they were full screen programs, and the terminal emulation wasn't working. So, I just stopped and went back to what I was doing.
This turned out to be a blessing in disguise. For this what the heart of the UNIX explosion. Everybody and their mother had some new box running some sort of UNIX, and we were installing software on all of them. While I spent my day in SCO on 486/66 (Shared by 8 other people), we were installing on Suns, IBM, NCRs, DG, Sequent, HP, and probably something else. I was always on someone else machine.
vi, of course, was everywhere. Not so much Emacs. I was also working in their environments, not mine, so box stock was the norm. And at the time, vi was more than suitable and capable. I still use vi pretty much the same way. Today I have multiple windows, unlike back then, but beyond that those formative years were so ingrained, those patterns and habits stick to this day. vi doesn't need plugins, it has bang-pipe. My file systems (notably tmp) are littered with x.x, y.y, z.z, etc. files adding as ad hoc cut and paste buffers. If I couldn't do the work with bang-pipe, shell out, bonk on some data in /tmp/x.x, pop back into vi and :r /tmp/x.x. Is it a single keystroke? No. But it's not in vi either. yyp is about as short as you can get.
Later, as I moved into Java and Python, I started adopting Emacs. I was particularly attracted to its auto formatting support for Java. Later on I chose Ant (Java build tool) because is had a -emacs switch to make the output compatible with emacs so I could jump to compiler errors. But that's stock behavior in emacs, we get that "for free", Ant conformed to emacs, vs the other way around.
I still kept my vi habits in emacs. If I wanted to refactor something, I was more apt to do something like vi `find . -name "*.java" | xargs grep methodToRename` than use emacs. I had multiple windows, so this was simple to do. Since Java is strictly typed, it coped well with yelling at my ham fisted endeavors when I went stomping through the code base.
I finally moved to an IDE, NetBeans, around NB 5 or so. Auto complete spoiled me.
Today my use of Emacs is mostly only for Lisp, and even then my Nerd Cred isn't up to par. I don't use Slime. I use emacs for lisp almost solely for auto indent, and paren matching. vi's lisp indent isn't spectacular, but emacs' is pretty good. The paren matching is about par, it doesn't bother me to use % in vi to test parens, but emacs is better. Then, I just ^S, and reload the file in my REPL.
I've tried Slime, but simply I don't do enough Lisp to make it worthwhile. It doesn't stick, so I have to relearn it when I come back. Just not worth the bother. I just want to work and get stuff done, not fight tools. Emacs on the Mac works well enough out of the box for me. Scroll wheel scrolls, Cmd-XCV cuts/copies/pastes, I can mouse around and double click things. You know, text editor. I also like messing with elisp in the scratch buffer. Even an old guy like me can remember ^J.
Basically what I've learned in my computing career, having to jump around every place, there's one commonality that's at every ___location I visit. Me. Rather than relying on adapted environments, I rely on an adaptable me. I like tools, I use tools, but I pick tools that work well out of the box. I want a tool, not a kit. Unix, thankfully, comes with a base set that I learned a long time ago. The important ones (important to me) have stuck with me. I can awk all day long, but I can't even spell 'perl', and it's my go to shotgun if I need it.
I have a strange nostalgia for the old Unix days that I was too young— perhaps not even alive yet— to experience the first time around. It's what draws me to learning and using things like vim, Perl, awk, sed, etc. Those tools feel arcane and mystical.
I've been there too. Installing, trying, running older and older Unixes in SIMH. 4.1BSD, 32V, V7, V6, all the way down to V0 on the PDP-7 with the help of tutorials on gunkies.org.
I still keep a neatly organized folder of primitive Unix systems with their (tiny) disk images and SIMH boot scripts.
But going all the way back to the Big Bang at V0, a funny thing happened.
The essence was still missing. Because indeed the open-source foundations weren't really born from Unix and the PDP-11. I only had focused on the technicalities.
No. The missing half of the puzzle is ITS and the PDP-10.
This is where the hacker movement, GNU and the free software philosophy were born. The world of Stallman versus the world of Thomson. The root of emacs, LISP, TeX, and many more. Which interestingly, are both older and more timeless than the Unix part of the puzzle.
After the demise of the PDP-10 in the 80s, Unix (and ultimately Linux) just happened to be a convenient hardware abstraction layer to carry the torch, to run what really mattered. Unix had been the tool but not the essence.
This is where I reached the end of my journey: ITS, emacs, and the birthplace of the hacker and free software spirit. I was enlightened, and the words "GNU's Not Unix" finally made sense!
Disagree. It's definitely falling behind in certain areas such as LSP support but overall it is just so much better than anything else I've tried in terms of moving around, macros, regular expressions that do what they're supposed to do, stability, stability of user interface (I could open an Emacs from 20 years ago and start using it immediately), quick and thoughtful response to bug reports…
It just works for me. It really, really does need some improvements in places but in other areas everything else just lags behind.
> I rarely hear people talking with excitement about WebStorm or VS code.
VSCode? It's got its fan base and it's quite vocal. Actually, Didn't VSCode collate the majority of the former Atom users, as Atom collated the majority of SublimeText before it?
First, interesting (and proper) user of "collate." To me, until this moment, it meant basically "to sort," but I looked it up to see if I was wrong. It means to "collect and combine in order." Neat.
I'm an editor vagabond. I went from Ed 4 to Notepad++ to JEdit to UltraEdit to TextPad to Sublime Text to Atom to VS Code.
Of all of these, Sublime Text is the one I still use every day. TextPad on Windows was the other one that was sticky, though Sublime has replaced it. I kept dabbling with Emacs, kept knocking into vi flavors for "just getting it done."
Perhaps it's time to find a home with Emacs and try to use it for everything. But there's always that next one... maybe Xi, maybe NightCode (nope), maybe Edita...
Emacs and vi will still be there, and I'll probably pay for the next three versions of Sublime Text like have the first three.
Thanks for noticing. I had to double check as well :p
I'm also on the lookout for my next "forever home" but I set the bar to only try a modal editor that acrually differs from Vim's modes. So, modal without vim-mode.
I share the same sentiment. It's taken me quite a while to be comfortable in Emacs, and honestly, I feel like I still need to spend more time to up my game in it.
My main gripe is dealing with several major modes at once, I still find that Emacs isn't the best at that.
I will say for anyone curious about Emacs, do try it out in your spare time. It's so much fun to customize and play around with.
At one point, my employer forced me to use Intellij products... I have no idea why anyone using Emacs would want that. It's awful all around. I also cannot imagine why would anyone come to conclusion that Emacs is like paper books. The UX is definitely better than in Intellij. And, feature discoverability is... well, it's for people with < 1 year experience. Who cares about their opinion? They know nothing, and are expected to not know anything.
> I rarely hear people talking with excitement about WebStorm or VS code.
You seem to be living in a very remote area where no programmers can reach you, beside those using Emacs. Yeah, people using VSCode talk about it a lot, given an opportunity.
In an average programming company, programmers might talk more about Emacs because for the overwhelming majority it's a mystery. It's the same how others might be driven to discuss UFOs or weird cultural kinks found in distant lands. But, really, it's not an indication of anything.
Emacs is the best. I do not hesitate to recommend it. Will it work for you? I don't know. Might it be exactly what you were looking for? Yep! That's how it was for me: it gave me everything I ever wanted and more. Period.
i get that, though i would rather compare it with chopsticks than vinyl records.
you use emacs to do stuff, you dont just listen to/watch it do its thing.
chopsticks might not seem like a good metaphor at first glance, as they are much more simple, but they are highly compatible with a lot of tasks and can be utilized in many ways that a fork, spoon, spork or colander just wouldnt handle as well. to my mind, the simple thing hidden in emacs' complexity is that it is a closeted lisp machine
Both metaphors seem apt. One is leaning towards how a product makes a person feel when using it, one is about what the product offers.
I hear arguments around what products can offer me all the time, they make sense, but I generally go with how a product makes me feel. Probably more than I even realise.
I don’t use Emacs, I do whisk eggs and fish doughnuts out of oil with chopsticks, I couldn’t fully say why for either.
oh i get it and i will contradict my own saying "you dont need GPU for handling source code" when i talk about my personal projects, but there is a time and a place for all the tools there are: some have janky handles, some have single-purpose nibs, others are as customizable as your regular homeowners house.
i am still a bit iffy about emacslisp, but less so than before i grokked CL (thanks for that goes to "practical common lisp" by peter seibel)
but: whatever floats your boat will keep your boat afloat :D
Just wanted to mention: the Community Edition of IntelliJ is open source. I used to routinely build it from source (but haven’t tried that in a few years). You might have fun making the extensions you want for more extension languages.
I have been using Emacs for 40 years and still love it, but I do find myself using VSCode more often now for Python work. Emacs has very good CoPilot support, but it sometimes lags a bit behind the support in VSCode. I also have started using a proprietary MarkDown editor instead of Emacs or VSCode.
For me a big draw of Emacs is that I have it easily configured for almost all programming languages I use.
I would assume that many people here do some work on free software. If people producing free software are not able to comfortably develop free software using only free software, then we have lost something important.
We likely have lost something. It's like global warming. Everybody talks about it as if they care, but if you still drive a car, do you actually care? No. Not enough to stop contributing to global warming.
It's the same thing with free software. I care, but not enough to stop me from using the easiest thing out there to use regardless of whether or not it's free.
Let’s not exaggerate; many people do care enough to have it affect their behavior. If there’s something you “care” about, but this does not affect any decisions you make in any way, do you actually care about it?
You can care about something, but have other contributing factors to your decision that override that care.
I care about the environment, but I still drive an internal-combustion vehicle, because NOT doing so isn't really an option where I live.
I care about issues of poverty, but enough to minimize all our expenses in order to give away more funds, because we want to be able to enjoy our lives.
It’s not meant to be taken as an absolute binary; it’s a question one should ask oneself. If you think you “care” about something, but never allow it to influence any decisions, you should really question yourself whether you actually care or not. As you say, the answer might very well be “Yes, I care, but there aren’t actually any options to express my precise level of care. The choice I make might be the same as if I didn’t care, but that’s because choices are limited, and my decision is ‘rounded up’ to the same choice I would have made if I did not care.” It is valuable to examine one’s own choices like this, because it causes you to notice when an alternative which is acceptable turns up.
The answer is: No, I don't actually care. I wouldn't say it's complete apathy though, I can still recognize that it's not exactly the most moral decision.
I agree, let's not exaggerate, if the overwhelming majority in aggregate acts in the exact same way, the aggregate action overwhelms the minority action.
In this case, most people don't care and share my viewpoint on the situation.
When I open Android Studio I often think: "Man, how lucky we developers are, we have such great tools to do our work." I thought the same about Visual Studio with Whole Tomato's Visual Assist. And VS Code is not quite there, it has a chaotic keyboard navigation + highlighting issues, but it is a pretty good tool, for being a text editor.
It's been a few years since I last touched it, but Android Studio is the last thing, that I would ascribe "great tool" to. I ended up coding views by hand in the XML, because the graphical editor would go out of sync or render things wrongly. As far as I remember I also had to manually code in the XML event listeners for clicks, because the GUI did not offer that. All it did benefit me with was project structure and being able to press a button to put an app on a USB connected phone.
I know you are doing a more vague accusation, but I don't appreciate being cast as bullying people into using Emacs. :) (Smile is intentional, not trying to be aggressive here.)
There is an odd aggression against Emacs that typically does lead to people having to go to extra effort to justify why they use it. And I can agree many of the justifications can feel like a stretch. They aren't false, though. Nor are we working on some archaic thing that only we can appreciate.
I'm also always amazed at how we think Emacs is somehow more archaic than anything else in a computer. Getting my kids into computers. It is Scratch to start, than probably crippled Python environments. That they are almost certainly going to break and wonder what happened. We even got started on some Arduino stuff, and their IDE is not bad, necessarily, but don't pretend like it is easy and quick in ways that Emacs isn't. Want to make a small game? Good luck, as there are no other environments for that anymore. (Used to, the computer booted into a BASIC shell in ages past.)
And this is avoiding the environments for content creation. Blender is amazing. And amazingly hard to use/explain. Fusion? TinkerCAD is at least easy to explain. But again, very easy to screw up in. (And I'm growing rather tired of all of the times I come back to a computer with hundreds of tabs in a browser all convinced they need to save data.)
All of that is to say, computers are tough. Period. I hope people can find a comfort zone for creation. But I am not convinced there is a single answer there. And more than happy to share what has worked for me.
Emacs has the best tutorial. It’s built in. And once you’ve completed it you are ready to use the whole system. Then you read the elisp intro and bam, you’re extending your editor. You can easily tackle both documents in a day.
I have only used IDEs and tried getting into emacs because I heard so many times how great it is, but it was the learning curve paired with the lack of good tutorials for beginners that made me eventually give up.
If you're actually interested in learning, there's a pretty good series "Emacs From Scratch" on the systemcrafters youtube channel.
He starts with a completely empty emacs config and builds it up to a full blown IDE explaining how everything works along the way.
Some of the things he does, there are better alternatives these days but most is still relevant and it'll teach a lot about how emacs works.
That said, emacs is more of a hobby than an IDE. If you just want to get work done, using something like vscode or intellij or whatever else makes way more sense. If you find it fun to tinker around and customize your editor you can make emacs incredible, but it's something you have to want to spend time on.
The Ingebrigtsen quote is meaningful. One should think of "using Emacs" not like "using Vim" but like "using the JVM."
Emacs is a powerful platform for building hackable, command-and-ui driven applications. You may not like the text editor that ships with a default Emacs install, but you don't have to use it! There are others (e.g. evil.)
There are also other applications. Some of my favourites are
- calc (desktop RPN calculator with advanced functionality)
- magit (context-aware git UI that interacts seamlessly with the git command line)
- sunrise commander (orthodox file manager that thanks to TRAMP can visit remote filesystems as if they were local)
- ediff (diff reconciliation between files)
and my train is coming now so this is where the list stops but it could go on for a long time.
Even though I've been using emacs as my main IDE for ~3 years (when I switched from Java in IntelliJ to Go), and using it for non-IDE tasks for ~5 years, I wouldn't recommend anyone builds a command-and-ui-driven application in Emacs if they have any expectation to use it outside of the Emacs ecosystem.
For example, I love magit and find it much nicer than many Git GUIs, but I would still recommend something like Git Kraken (or just the GIT CLI) to someone who is not already using emacs for other things.
Emacs is extremely idiosyncratic, and the barrier to entry of using an Emacs-based app is nowhere near as small as using a JVM-based app (and even that is too much for most uses).
"Calc was originally started as a two-week project to occupy a lull in the author’s schedule.
...
Emacs Lisp would surely reach its limits long before the project got too far out of hand.
To make a long story short, Emacs Lisp turned out to be a distressingly solid implementation of Lisp, and the humble task of calculating turned out to be more open-ended than one might have expected.
Emacs Lisp didn’t have built-in floating point math (now it does), so this had to be simulated in software. In fact, Emacs integers would only comfortably fit six decimal digits or so (at the time)—not enough for a decent calculator. So I had to write my own high-precision integer code as well, and once I had this I figured that arbitrary-size integers were just as easy as large integers. Arbitrary floating-point precision was the logical next step. Also, since the large integer arithmetic was there anyway it seemed only fair to give the user direct access to it, which in turn made it practical to support fractions as
well as floats. All these features inspired me to look around for other data types that might be worth having.
Around this time, my friend Rick Koshi showed me his nifty new HP-28 calculator. It allowed the user to manipulate formulas as well as numerical quantities, and it could also operate on matrices. I decided that these would be good for Calc to have, too. And once things had gone this far, I figured I might as well take a look at serious algebra systems for further ideas.
... (and on and on and on) ...
Final thanks go to Richard Stallman, without whose fine implementations of the Emacs editor, language, and environment, Calc would have been finished in two weeks."
If you look at its feature set, it is amazing how much can be done with it. It has nifty features like evaluating formulae inline in any buffer, and replacing the expression with the result. Expanding things to their LaTeX representation, etc.
I spent a lot of time trying to learn it. I use it for simple calculations, but ultimately decided it is not worth my time to go much further. That same effort would be better spent learning Sage, with a lot less cognitive load. And there is decent integration between Sage and Emacs.
Same here. I knew about RPN before Calc, and knew there were calculators that used it, but it seemed bizarre to me. Once I started using Emacs, I decided to see what Calc was all about, and finally realized how slick it feels. It's really cool to need to do some math while coding or writing, hit a quick keybind, and have a full-fledged calculator right in my editor.
And the cool part is you can do things algebraically, too. Even solve for variables. Really crazy program.
OK. Here's a usecase where I found emacs to be wonderful.
I had to email the grades, together with totals, and class averages to many students in a class.
I tried fiddling with Excel and Google spreadsheets and scripted mail merges. Then I realized I could do it emacs.
Export the gradesheet into csv, and convert to an org table.
Carefully record a macro where you copy paste the name of the student the mark columns into a mail window (I used gnus), copy paste them into a calc window, do the calculation, copy the result onto the mail, and email the student. Go to the org buffer, and go to the next line. This took about 12 minutes to get right.
Keep pressing f4. Sending individual mails to 125 students took <5 minutes.
Maybe this is overkill, and I am sure excel wizards can do it in a few minutes. Nevertheless, I was surprised - if you spend time carefully recording the macro, the Emacs ecosystem (org+gnus+keyboard macros) is insanely powerful.
You can also do this with the system's built-in mail program. I set this up for doing bulk emails a while ago and it has proved very useful and versatile.
(defun compose-mail-macos (&optional to subject body)
"Compose a message using macOS's default mail program."
(interactive)
(start-process "Open Mail Message" nil "open"
(concat "mailto:"
(when to to) "?"
(when subject (concat "&subject=" (url-hexify-string subject)))
(when body (concat "&body=" (url-hexify-string body))))))
(defun compose-mail-macos-multiple (list subject body)
"ADDRESSES should be a list of email addresses in the form of:
(setq mail-list '(\"Mail 1 <[email protected]>\"
\"Mail 2 <[email protected]>\"
\"Mail 3 <[email protected]>\"))"
(while list
(let ((to (car list)))
(compose-mail-macos to subject body)
(setq list (cdr list)))))
It's not an overkill. He spent 12 minutes developing the solution and then 5 more minutes for actual sending of 125 emails. That's 17 minutes in total.
I assume doing the same task manually would take him at least a day or two, with the possibility of making numerous mistakes by doing it.
I used Emacs for a while and now I use Intellij. Now I don't understand the appeal of customizing the editor to such degree. I'm not that unique. I just want stuff that works. Give me the same setup as everyone else so that when issues arise everyone will push for them to get fixed and everyone can help each other.
Most real Emacs users I know don't spend much time configuring it. Including me.
I continue to use Emacs not because it has the best UX--it doesn't. I use it because it's a stable foundation that I'm confident will be around as other IDE/editor fads come and go (Eclipse, Atom, Sublime, IntelliJ, VS Code, etc.). Sure occasionally I tweak my config to keep up with ecosystem developments, but that's much less dramatic than changing editors every few years. There's no particular reason I use Emacs over vim other than my own momentum, I think they both have this property. I think IntelliJ comes in second place here because the incentives of JetBrains are pretty well-aligned with developers' best interests (I definitely can't say the same for VS Code...).
I'm not that old of an engineer, but the consistency of using the same tool for 8 years continues to compound. Interacting with Emacs has become second nature, I've built up a small collection of utility Elisp functions for getting stuff done quickly, etc. It definitely compounds. This is a big deal for me. I can't find a stronger, longer-lasting foundation to build a compounding developer toolset on than Emacs.
I started using Emacs because it could actually run on my cheap netbook, and continued because I'm addicted to Magit and Tramp plus I can't retrain my window management muscle memory. Tinkering with it came naturally over the years in tiny increments, the same way VSCode users change a setting or install a plugin. The emacs.d folder is a git repo that follows me from system to system. Customising it isn't a selling point, it's more just the natural outcome of spending a lot of time near the editor.
Choosing Emacs for its low memory and CPU footprint is probably very ironic to anyone from the era of Eight Megabytes And Constantly Swapping jokes.
It still does use a lot of memory, but thankfully most systems have that to spare, and CPU usage is much more optimal now thanks to native compilation.
I use Visual Studio Code now for pretty much this exact reason. The only configuration I need to do is to install the right language server extensions for the code I develop, but even this is mostly handled by the "It looks like you're writing Rust code. Do you want to install the extension to handle this file type?" dialog that pops up on first use. Everything is auto-updated, settings synchronized across devices, and default settings are mostly ideal.
Reaping the benefit of everyone else's hard work at improving vscode is awesome. It just gets better over time without me having to do anything except occasionally read about new features in the release notes. Spending hours twiddling in emacs lisp to get things configured just right is just wasting my limited time.
You also get the benefit of everyone else’s hard work with Emacs. One of the differences is that it’s such an established ecosystem, that instead of individual extensions just getting better, with Emacs they’ve yielded shared abstractions that make _new_ extensions trivial and much more consistent than with VSCode (which is nevertheless still an excellent editor these days).
I also don’t understand why people think spending time on the tools they use to do work is wasted. You either believe software creates value or you don’t. If your time is so limited, eliminating toil seems essential.
> If your time is so limited, eliminating toil seems essential.
The counter point to this is usually:
What exactly is your toil as a professional software developer (or associated profession) that is eliminated with a "better"[1] editor in 2023?
Refactoring is more powerful with an IDE, for mainstream languages. For non-mainstream languages 95% of what Emacs enables can be done using multi-cursors and a macro language built in to the editor, and we're in 2023. Those kinds of editors are a dime a dozen :-)
Editing data dumps or whatever is probably better with an advanced editor (I generally use Vim for that). But it's such a rare occurrence.
Writing code is super easy in an IDE.
Most of my toil is unnecessary meetings, unnecessary reporting, unnecessary social stuff. Emacs can't help with any of that.
* * *
[1] To note, "better" is strictly a claim. I'm quite sure there's no peer reviewed study that can prove conclusively that Emacs/Vim users are more productive than non-Emacs/Vim users, just due to their usage of Emacs/Vim.
The "toil" is anything involved in software development that's boring and repetitive. There's a computer right there that's for that stuf. My biggest frustrations come when I'm prevented from bringing the power of that computer to bear on a problem that isn't one of the ones envisioned or prioritised by the makers of my tools, and they didn't think to make it easy for me to extend them myself.
Emacs isn't an editor, it's a (very) rapid development environment for textual UI applications. Text editing is a large class of such applications but there are plenty of others.
Case in point: at work we use a job scheduler with a horrid web UI. I knocked something together in a couple of hours in emacs that eliminated that pain from my life and allowed me to explore our environments much more freely. If more of my colleagues used emacs they could share in the joy. I don't have anywhere near the time I would need to make something they could use without it.
Meetings, reporting and "social stuff" isn't much of an issue for me as I've been very clear in every interview I've had that I have no desire to take on managerial responsibilities at any stage of my career.
> Case in point: at work we use a job scheduler with a horrid web UI. I knocked something together in a couple of hours in emacs that eliminated that pain from my life and allowed me to explore our environments much more freely. If more of my colleagues used emacs they could share in the joy. I don't have anywhere near the time I would need to make something they could use without it.
Other devs would (and regularly do) just whip up something using shell scripts and command line tools, or write their own CLI/TUI/GUI/web service/app for the exact same thing. There are myriad viable ways to automate things.
> Meetings, reporting and "social stuff" isn't much of an issue for me as I've been very clear in every interview I've had that I have no desire to take on managerial responsibilities at any stage of my career.
Meetings, reporting and "social stuff" happen as an individual contributor because you need to sync with customers, peers, bosses, plus customers and bosses also expect you to report your progress. Social stuff isn't going out to lunch or dinner, it' just regular interaction or support.
I'm glad that you get what you want, not everyone does.
I'm just pointing out that there are many ways to happy coding and Emacs is just one of them.
A needlessly crabby response. I don't think anybody claimed emacs was the only way to code happily.
I was just explaining what the "toil" is in my life and how emacs materially alleviates it. The examples you give don't, in my experience, allow a useful interactive UI to be knocked together anywhere near as quickly as it can be done by an experienced user in emacs. YMMV - use whatever tools you like and manage your career how you please.
> Other devs would (and regularly do) just whip up something using shell scripts and command line tools, or write their own CLI/TUI/GUI/web service/app for the exact same thing.
The difference is time of development and flexibility of tge emacs result using the same universal plain text interface you use in emacs every day for me.
For non-mainstream languages 95% of what Emacs enables can be done using
multi-cursors and a macro language built in to the editor, and we're in
2023. Those kinds of editors are a dime a dozen :-)
Are they? Multi-cursors, sure, but what other editors have a macro language that combines the power and accessbility of emacs lisp? The only other one that comes close is vim, and, as many critiques as I have of emacs lisp, I can firmly state: it's a lot nicer to use than vimscript.
But other than emacs and vim, which other editors allow me to interactively automate portions of my editing workflow? All the other IDEs and editors that you've cited, like IntelliJ or VSCode require you to either find or write a package. That's a much bigger step than just interactively evaluating some lisp to do a one-off thing.
There are many text editors extensible in Lua or in Python. They generally don't allow messing with the innards as much (Firefox proved that's a double edge sword with its extension, it's not an unalloyed good).
And Emacs Lisp doesn't feel super accessible to most software developers under 40. Almost all its conventions come from a small little island, it's like marsupials in Australia, their own little parallel evolution.
> But other than emacs and vim, which other editors allow me to interactively automate portions of my editing workflow? All the other IDEs and editors that you've cited, like IntelliJ or VSCode require you to either find or write a package. That's a much bigger step than just interactively evaluating some lisp to do a one-off thing.
Devs generally write one-off or maybe reusable shell/Python/... scripts for that. But some of the examples I listed allow you to do a lot of that using Lua.
There are a ton of workflows out there, other devs don't just bang 2 rocks together because they can't automate everything <<inside>> the editor itself :-)
> And Emacs Lisp doesn't feel super accessible to most software developers under 40.
Or over 40 (I'm 42) :)
> Almost all its conventions come from a small little island, it's like marsupials in Australia, their own little parallel evolution.
This is a great analogy. And people forget that to program any system effeciently you need to know that system. Not necessarily inside-out, but good enough. A brief look at any emacs config will show you just how many weird and inconsistent things you have to contend with: major modes, minor modes, hooks, global variables, global functions, mode-specific global functions, special lists, non-special lists, and a myriad API calls and functions in between.
Wikipedia says that emacs has 10 000 (ten thousand) built-in commands [1] That's probably on par with JVM :)
The worst part for me is that I wanted a few "simple" UI tweaks with Emacs. I really wanted to use it.
But I wanted it to have a native tab bar and I wanted to move the command bar at the top, with dropdowns instead of "expand-ups" (turns out, I read right-to-left, top-down, not right-to-left, bottom-up. You can't have either of those, in the world's most extensible editor :-(
Emacs has had tab-bar-mode since 27.1 and tab-line-mode since 27.2. As for the drop-down minibuffer (I suspect that's what you mean by "command bar"), you can use something like vertico-posframe* and put it at the top like so:
> but what other editors have a macro language that combines the power and accessbility of emacs lisp?
Is it accessible? Why would I want to spend time learning the idiosyncrasies of a 40-year-old editor to write something that I might use once in a blue moon?
I think my time is better spent improving my build and deployment environments instead of something like customizing my text editor. More of my work is in tying command line utilities together
Maybe I don’t know what hardcore emacs use is like.
Yeah, I suspect the fundamental disconnect is that some people think of the terminal as the dev environment and something else is used purely as a text editor. Emacs edits text, but it’s an environment beyond that (one which happens to also contain a terminal).
I think you're missing the point. With vscode I literally don't have to do anything. It just magically gets better every time I start it up. Most people I know who use vim or emacs don't have it setup to auto-update extensions, and even if they did they wouldn't automatically fetch and configure those new extensions you mention.
What I'm objecting to is the very idea of a highly customizable editor.
> It just magically gets better every time I start it up.
Some of my coworkers violently agree, but at least 20-30% get annoyed when autoupdate removes/ changes some feature (pane splitting recently I think) and they have to adapt their workflow.
Yeah, with more experience I have realized that most customization is not better
A certain level yes, but doesn't need to be all, end all
VSCode solves most of my issues.
"oh but in Emacs you can do..." a thing that I either don't need, or I don't care about or I can do using a web service or some other offline program or maybe even a VSCode plugin or a short vim script.
> "oh but in Emacs you can do..." a thing that I either don't need, or I don't care about or
or it's already available in pretty much any IDE out of the box. Most people advocating for emacs or vim usually have no idea what a modern IDE is, and pretend modern IDEs have not surpassed win3.1 notepad in terms of functionality.
For me, the appeal is not so much that Emacs is customizable, but that it's basically a live coding environment for working with text, seamlessly integrated with all the usual functionality of a text editor.
I often write short programs interactively to manipulate the text I am working on, and have a whole bunch of Elisp code for common things that come up at work. For example, transforming a pasted ad-hoc spreadsheet column into sql insert statements (because nobody wants to pay to add that functionality to the software, and they email me instead). I used to have a bunch of code for generating Java boilerplate, and even entire classes but the situation has improved in recent years...
Sure I could write scripts or conventional programs to do these jobs, I just prefer the interactivity and fluidity of Lisp environments. Also, being an Emacs user means I can write Lisp at work and get away with it.
Having said all that, I tend to primarily use a dedicated IDE, with a general purpose text editor in the background. I will use Emacs alone when I am writing plain text, Common Lisp, or simple stuff that doesn't require a load of configuration or a complex toolchain. I want the IDE to take care of that for me.
Intellij out of the box offers such a crappy text editor, I feel like programming with one hand behind my back... well, actually even worse, because I'm forced into using mouse and a crappy text editor at the same time when touching this stuff... This has nothing to do with extending the editor. People making Intellij editors simply don't know how to make editors, they don't have a good understanding how a professional would want to edit text. Their whole approach is based on satisfying inexperienced users (because that's the only thing they know).
As for helping each other: yes, my wife is using VSCode (she's also in IT, but more of a scientific research that uses IT wing). When she has problems, I SSH into her laptop and use Emacs.
And, for users who have problems with their editor, I can only say: git gud. If you are so pathetically bad you cannot solve problems with the only tool you are supposed to know how to use well, then take a class on how to use it, spend a few weekends reading documentation. It's your responsibility to know this stuff, if you don't, you are a liability for your team.
No, I don't. it's the people who use Intellij need to try other things, expand their horizons to understand how awful their editor is.
This is usually very visible when an editor tries to have something they call "Emacs keys" or "Vim editing" etc. Where once you try it, you instantly realize that the editor trying to mimic a decent editor is just so far behind, they, in principle, are incapable of implementing anything like Emacs or Vim.
Intellij products are targeted at amateurs, they aren't meant for people who are professionals at text editing. Similar to how you can buy sporting equipment, for example, designed for people who just want to stay in shape / have something comfortable to go to the gym in, and equipment meant for professional athletes. Eg. bicycles, where a typical city bicycle isn't even trying for the niche of being used in Tour de France.
Pretending that there's some kind of competition between Intellij products and Emacs is like thinking that you'd do just fine taking your average Home Depot 200 Watt drill to a concrete wall.
I am actually a Neovim terminal user myself and I am smiling at this. The Intellij text editor for a power-user who has actually done their research is ridiculously full-featured out of the box without needing a PhD in elisp and several hundred (more like a thousand) hours of config time.
Comparing it with emacs is like comparing a smoothly running Tesla (Intellij) with a bullock cart of misc automobile parts (emacs). Sure you can build your Frankenstein car after a lifetime of effort, but most folks want a better quality of life. The vast majority of people don't want to build their own automobile (or washing machine).
She's not on my team and doesn't need to be a professional text editor. She can be very bad at editing text, and still be productive at what she needs to do. And so are most people, even in IT.
I also had to work with a mostly Java shop (a branch within HP) where I was on the ops team. A significant portion of my day was spent walking between cubicles and "fixing" Maven builds. I wasn't really fixing the builds though. Every time it was because another Java dummy couldn't figure out how to do something trivial in Intellij or Eclipse and were blaming the ops for that.
No matter how much I despise Intellij products, the average Java programmer at the time seem to be incapable to internalize even the bare minimum these editors require to function. I call this "the race to the bottom", a situation where technology encourages its users to be dumber, where, in turn, the dumber users make technology worse by requesting dumb features. And this is how Intellij is. It tries to cushion the fall, to put a fence around every useful but potentially "dangerous" operation by limiting what users can do to a fixed number of choices, where free-form input would've been appropriate, by creating layers of renaming of basic stuff the users need to work with in a failed attempt to "make it easier to understand", by hiding things that it perceives as being "out of scope", giving no easy way to reveal the hidden features.
So, yeah, these programmers were a liability to the company. So much so they needed to payroll a dedicated person to do their work for them. And, of course, a dedicated person could only service single Java dummy at a time, while the rest were taking a break downstairs playing table tennis or socializing in cafeteria. Good times!
I'm not that unique either but i just suffer in other editors, serious pain. I totally agree emacs can be a sinkhole of config nihilism. But there's something else. It's an ergonomic flattening... I don't have a right expression for that. I'm not a bleeding fanatic, I can recognize flaws (I prefer vim moves for instance) but everytime I see someone using something else I cringe hard.
IntelliJ is very configurable, and there are some settings and plugins I couldn't live without (such as the Vim plugin). I've also been through a Vim-as-main-editor phase, but I'm now using Rider (a JetBrains IDE) as my main editor, VSCode as my secondary editor (for things where opening Rider would be impractical), and NeoVim for some one-off things and Git commit messages. Rider/VSCode with Vim plugins get you the best of both worlds, a friendly and smart IDE with great text editing tools.
I use Spacemacs for this reason. Building up from scratch might be most satisfying, but I don't have the time or knowledge for that. Vanilla Emacs is not so easy to find your way around IMHO, and I find the discoverability and batteries-includedness removes a lot of friction. I guess I'm trying to start with everything and pare down, rather than the other way.
I use IntelliJ for writing Java code. Emacs can do a lot, [1] is a good 5 minute introduction, but I think I prefer a GUI-first mouse-first UI.
I use Emacs for general text editing, so for most non-Java code. I occasionally edit individual Java classes with Emacs if I have something repetitive to do, and I know an Emacs macro (F3, do things, F4 to save, F4 to run) can do it.
I use Kate when I want its nice tabbed views with a terminal at the bottom. Often this is things like moving content between 20 different documentation files.
I use vanilla Emacs for everything. For me customisation isn't what matters, it's having an editor that will never lag, requires barely any ram, and can be used over SSH on pretty much any machine.
But Emacs is incredibly light for the current generation hardware... and it's been incredibly light for probably 15 years or more.
On my "small" laptop, I only use Emacs... Trying to run IntelliJ or VSCode makes the laptop burning hot and forces the fan to keep running. With Emacs, no matter what I do, it's always quiet and cool.
One gripe I have with Emacs is that it doesn't boot instantly enough. Annoys me every time I edit a Git commit message.
Though it's not horrible enough that I found the courage to set up an Emacs server, as easy as it is… Anyway, it would be nice if it could just boot instantly by default.
> One gripe I have with Emacs is that it doesn't boot instantly enough.
You must have accidentally closed it. Closing Emacs or your Web browser are common mistakes, and as you will surely have realized almost immediately, you needed to re-open either program within minutes.
Emacs takes 10 seconds to open. Firefox takes 15. Yes, those are wasted seconds, but it's not like they are anywhere close to the largest wastes of my day. (Hell, I'm writing a comment in HN right now!)
It's different for things like VS, Pycharm, VSCode, or Eclipse. But emacs isn't there.
> You must have accidentally closed [Emacs]. Closing Emacs or your Web browser are common mistakes, and as you will surely have realized almost immediately, you needed to re-open either program within minutes.
It makes launching emacs practically instant because it’s always running in the background—emacsclient connects to the already running instance so you get to skip the startup process.
Why are you using emacs, then?
Emacs GC pauses are awful. The input lag is on par with vsc. There is work being done on both, but right now it's terrible.
I'm just here because I want buffers that can be scaled individually along with good vi-emulation. I'll never pretend that the performance is any good
I'm more of a vim guy, but "I get it". I started using these "serious" editors back in college and eventually settled with vim over emacs. I don't wanna get into the whole editor wars - it's like picking a Pokemon at the start of the game.
I went through the whole phase of adding a bunch of plugins, custom macros and have a huge .vimrc file that, once in a while, would break if I was using the wrong vim variant {vi, vim, nvim}. For the sake of this argument, emacs users face some form of the same too.
It got to a point where all my hardcore configurations made my editor experience diverge even further away from the promised "out of the box" experience, and not on par with autocomplete functionalities available in modern IDEs like VSCode.
So now I'm on VSCode. A M1 MacBook can handle it, so I told myself to quit being a masochist, and that itself saves me hours especially navigating a big and complex codebase. But I remember how to use vim, and that comes in handy if I have to SSH into some remote machine and make some tweaks to scripts.
"I don't wanna get into the whole editor wars - it's like picking a Pokemon at the start of the game."
This encapsulates my feelings completely, haha. Both require so much investment and you spend a lot of time with them, just like the pokemon you pick at the beginning.
I don't use it much, but VSCode's vim plugin seems pretty good these days. I know everyone has a different subset of vim commands they consider essential, but everything I use regularly seems to work: change list, '/' for incremental search, f, marks, macros, split windows etc.
Actually, I may have just talked myself into using VSCode over MacVim...
At least for Emacs, dealing with big codebases isn't a problem. Modern approach to dealing with this is to use language servers. This is also what VSCode does. So, suggesting you have better autocompletion in VSCode vs Emacs (or Vim) is just a sign of not knowing how that works, because they are, literally, doing the same thing...
Gah, yet another instance of people treating Emacs like it’s a terminal application. It can run in the terminal, if a terminal is all you have, but you don’t want to do that. Use its default, graphical mode:
I think that the image there is old; it looks different when I show that screen. Try it yourself by starting (a graphical) Emacs and selecting Options → Multilingual Environment → Show Multilingual Sample Text
There are a million things to say here, and many have said them better than I can. But there's an important generational aspect to the discussion.
I learned Emacs in 1988 or so. Only a couple years before, I had traded my Commodore 64---on which I did real work, like writing term papers---for an IBM PC XT clone. WordPerfect. Hobbyist BBSer, but networking was in the future.
When I got to college, Unix and Emacs were a revelation. This is how it's supposed to work! And the background ASSUMPTION that you could understand everything, and control everything, was something nobody at the time would have questioned. With hindsight it turns out that understanding everything was a mirage and controlling everything was the gateway drug to possibly literal addictive behaviors, but that was the ethos.
I left CS after only a couple semesters, and my career has completely diverged from it. So it's a TOTAL FLUKE that today I can comprehend---god, the whole model! of a Lisp machine! of Lisp at all! For a young person starting with modern tools? Maybe we can agree that we all see the big chasm....
I’ve started to use emacs in my computer sciences school 30 years ago (EPITA in Paris). The Lab was surrounded by Mips, Sun, Alpha, … great time.
The only weakness of Emacs (according to me) was the lack of a good major mode (module) to edit web template : imagine editing a php block inside a javascript part embedded inside html.
After testing many modes, I started to develop web-mode (http://web-mode.org) that is now compatible with about thirty template engines. What a wondeful trip it was to discover the power of Lisp and what a pleasure it is everyday to know exactly what happens when I hit a key while editing an html file.
I am the only Emacs user in my company (kernix.com) but nothing would make me switch. I can not imagine using an editor that would not open in less than a second (or that would eat hundreds of Mo of RAM)
I Hope Emacs will see a usage surge with the inclusion of tree sitter… editing in emacs will be even faster and more robust. Not sure tree sitter is suitted for multi languages files … but for this you have web-mode ;)
I'm not even sure about the state of this in other editors: Emacs allows syntax highlighting of different languages to be used correctly in nested regions. For example in org-mode you can have source blocks of any other language and you can see them syntax highlighted correctly. Maybe some other editors manage this for markdown's tripple backtick syntax, but do they add syntax highlighting of various mainstream languages to their markdown "modes", or do they actually have that use their separate "mode" for that language, possibly recursively?
Would be great, if anyone could comment on that. I think Emacs using Elisp has natural potential to do it recursively and therefore easily correctly, instead of cramming other modes with syntax, that does not belong there.
I switched (over 7 years) from Sublime to Atom to VSCode to vim to neovim, to VSCode and back to neovim and even tried Helix before settling onto (Doom) Emacs a couple of weeks ago (lol)
Seriously, it feels unproductive a bit at first. But the productivity potential is 10x higher than any other tool or editor out there.
With org-mode, Magit, Projectile and dired, I already feel more productive than in VSCode or neovim. And more importantly, I feel like I'm shaping reflexes around the editor and thus creating my own workflow.
And evil-mode is the best emulation out there. I tried neovim inside VSCode but it's not yet there. So as a vim lover, I have two options (Neovim or Emacs).
The deal breaker was org-mode, It made me switch ... My organization skills are quite poor and I tend to forget everything all the time. But org-mode is a magical tool that's probably the best piece of software written to date !! And org-babel is quite cool too!
Anyway, the key takeaway is that my relationship with emacs is two-way shaping ... Meaning I can configure it to my liking with no barriers (other than elisp, I ask ChatGPT for help) and Emacs helps me shape my workflow and improve it.
It's not for everyone. It's not for most people. But it was a match for me :)
If you want to combine note taking for future self, learning, coding, and org-mode, I recommend another rabbithole: Literate Programming in org-mode. The features supported are very comprehensive.
What sets Emacs apart for me is that it, unlike a lot of "unix philosophy" tools, it deliberately takes a sort of systems approach. The often used analogy is that an architect never just designs rooms in isolation, but only changes a room in the context of the house. It's the whole arrangement that matters, not its parts. And you can't infer the performance of the former from the latter.
The minimal approach to have 'one tool do one thing' ignores that all the complexity is in the interactions. People praise magit so much I think because like all other tools for Emacs, it's designed with Emacs and the common interface and language in mind. It's implicit in every extension people build.
When people today struggle how to combine all their dozens of tools from notetaking to developing, to file search to git and struggle to fit it all together I think the strength of learning Emacs comes through. My guess is that this is also one of the reasons for the popularity of VsCode as it takes a similar approach.
Emacs to me is probably one of the better examples of The Right Thing (c.f. Worse is Better essay), where UNIX is one of the canonical examples of WIB.
I really like your point about systems approach -- it's definitely a very holistic, cohesive piece of software. This is probably one of the reasons that it can be very difficult to add new features to Emacs.
I’d just like to interject for a moment. What you’re refering to as UNIX, is in fact, Emacs/UNIX, or as I’ve recently taken to calling it, Emacs plus UNIX. UNIX is not an operating environment unto itself, but rather another free component of a fully functioning Emacs system made useful by the Emacs lisp interpreter, shell utilities and vital system components comprising a editor, mail reader, and other necessary user interface components.
With UNIX, the integration platform is the shell, hooking simple specialized tools through pipes and the shell language.
With Emacs, the integration platform is a Lisp environment, hooking specialized Lisp tools and Unix tools through Emacs buffers (or buffers regions) using the Elisp language.
So it's an extra layer, but if you look at it in this way you can see similarities: an environment that makes it easy to compose elementary functions into an integrated whole.
In both cases, it's most suited for people who are ready and willing to build their own specialized environment on top of a powerful platform. Although many users don't and stick to the basics too.
I'm not sure there is such a big divide: emacs is the OS in a way (in the same way a browser is one these days) and the tools are all the extensions (including those built in). The union of all extensions is more than the sum of all the parts. The difference is that the interface between tools in emacs is usually much richer than in UNIX (for example a buffer is a more complex abstraction than a file).
I have been a faithful Emacs user for more than fifteen years now, even using a version of Emacs on my Amiga back in the 80s when I was just a kid. Over time, I have ported almost every aspect of my computational life to Emacs, including my editor, IDE, git-client, writing, documenting, and workflow automation. While I love the tool and enjoy tinkering with it, I have come to realize that there are dedicated tools out there that offer a much better user experience with less effort.
For example, when it comes to emailing, MailMate is an excellent tool that I have found to be much more effective. And for programming, VS Code is unbeatable for the overall experience. When it comes to my personal wiki, I find that Obsidian is simply too good to use Emacs + Orgmode. And for quickly capturing ideas, the Drafts app with its javascript extensibility is sweet, and a big plus: it's also available on my mobile phone.
Ultimately, I have come to realize that tinkering is a luxury that not everyone can afford. While I still use Emacs extensively as an editor with macros for transforming text, I find that those who want to focus on the task at hand cannot afford to spend more time tinkering than doing the job.
In conclusion, Emacs will always have a special place in my heart, but I have learned to recognize the value of specialized tools that offer a superior user experience with less effort. However, I should note that when it comes to regex-replace across files, BBEdit is the only thing that can beat Emacs.
> VS Code is unbeatable for the overall experience.
What is this shilling for VSCode? It's awful. But, somehow everyone who says positive things about it either turns out to not know how those things work, or just saying something vague, never pointing at any concrete feature that makes it better than something else...
But, the reality of it is that all there is to it is a crappy CUA text editor with nothing special going on for it. There were dozens like it before.
So far, over the years of working with other people using this average-at-best editor the only remarkable thing I found about it is that it has a plugin that allows some Jenkins integration, which may be useful if you are in DevOps, but... I can live without it, not a deal-breaker, not by a long shot. The awfully lacking text editing abilities of this editor completely erase any benefit I could get from that plugin. Stuff like modal windows, mouse-only navigation, missing most useful commands of structured text navigation and proprietary nature make this tool a complete non-starter for me.
I can think of only two types of people who use emacs (same thing for vim) .
1. Old folks who are used to working with them and don't bother switching.
2. Young fellas who spend a significant amount of time tinkering and playing with config files.
VScode (VScodium really :) offers everything that emacs or vim has to offer (as far as editing file is concerned) with much less time spent in the config files. With that in mind, I still use emacs bacause I belong to that second category.
I abandoned Emacs for a couple of years and tried various "modern" tools (VS Code, Logseq, etc.). The "out of the box" experience never felt comfortable to me. Yes, Emacs can be a hassle to configure, but I can't help going back to it. I now use Emacs again with Meow mode, and my old configuration. I guess I'll use it for the decades to come...
I love Emacs & it's my go-to editor, but I struggle to offer a solid, logical reason why.
I only use a handful of packages, a smidge of Org mode, minimal customisation, & run Emacs in the terminal, so switching to something more modern should surely give me everything I need & many more features in spades. But nothing else scratches the itch despite my best efforts to move to something else.
Perhaps for me Emacs is like an old pair of slippers: comfy, familiar, does what I need it to without fuss. I can't say whether it's a good choice for anyone else, but this grey beard engineer likes it.
I'll help you with the reason: people who make Emacs are professionals at editing text. They understand what tools a good professional needs when working with text. The only editor that can complete with that is Vim. IntelliJ / MS / Eclipse products don't hold a candle to that, their authors simply don't know how to edit text well, and consequently don't know how to make tools to that end.
It's the same reason why anyone would buy Hasselblad camera over, say, Canon. Canon is fine for a person who simply wants to take pictures of things they want to remember. Maybe even for a student in photography class. But, if you are going to earn your money as a photographer... well, you want a tool that you can rely on. If you go to the Moon and want your camera to work, you'll choose Hasselblad etc.
> [Emacs is] a Lisp Machine with several compatible user interface modalities. Which is just amazingly helpful to [blind] people like me […] who are typically forgotten about these days. […] Emacs is a shining beacon in a dark age of canvases and decorative user interface design.
This. Even with my fairly correctable visual impairments, the way Emacs' text-driven interfaces and amazing search capabilities spare me from having to do any visual scanning is a blessing. I can always bring everything I need to see right in front of me, the whole interface scales perfectly, and I can easily ensure high contrast on everything I need to read, even with limited color vision.
The way that buffers can just live in the background and projects can simply be inferred from version control directories similarly free me from the entire spatial metaphor for open files, windows, projects, etc. No matter what window I'm in, I have the option to just list some open buffers, fuzzy filter as I type, and bring them directly into view. I run Emacs as a daemon so I can super easily pull up old buffers, complete with their contexts and undo histories and everything even if I close the Emacs frame (the application window) entirely.
I never have to scan or squint or interpret some tiny, inscrutable hieroglyph with Emacs. Every damn thing is searchable and filterable. And when I need documentation on some function or keybinding, it's the same story. I don't have to switch to another app and mouse around or toggle a browser extension to fix some dumbass website's choice of gray-on-gray text. It's just right there in my editor, clean and searchable and resizable/reflowable in the exact same way as my own code, in the fonts that I've chosen because I find them readable and pretty.
Emacs spares me from so much navigation effort while I'm editing, even without using any truly fancy features.
It's also a comfort knowing that if I should go blind before I reach old age, as is common in my family, I will still have access to that power and convenience through Emacspeak. I'd better start practicing!
I have been using emacs since around 2005. If you are looking to immerse yourself in emacs, then I highly recommend switching your windows manager to EXWM [1]. If you are looking to get over the learning curve, then I recommend buying the book Mastering Emacs [2]. If you are interested in learning new and creative ways to use emacs, then I recommend attending the next emacs conference [3]. Also, please join #emacs on librechat [4]. For IRC on emacs I really love erc-mode [5].
A bit off topic but a few years ago you posted about a calendar API, did you ever find a good one [0]? I was looking to use one too so was wondering if you wanted to discuss more about it and what your use case was.
Emacs is the only software I've ever loved. People use the word love a lot, but I really mean it. You know it's love when you can't stop thinking about it. You're so excited you want to tell everyone about it, but you can't really articulate what exactly it is that makes you feel that way.
Agreed. It's because Emacs truly respects the user. It is the embodiment of Free Software ideals. Those ideals center around community. Emacs helps us understand how capable we are.
It's also personal computing in the truly personal sense. No cloud, no silos, something that you can make work the way you want and grows with you over your career and eventually becomes like a well-worn glove.
Emacs is great, but I don't advocate it anymore, even though it still has some great merits.
The main reason is that I'm concerned that we've lost ground on some very important ideas, for which we should've done a better job onboarding new techies in the last decade or two: open standards, open source, libre software, privacy, information security, etc.
There's vague stereotypes that I've seen newbies use to dismiss those ideas, bundling concern about those ideas in with "tells you that you should use Emacs" (or Vim). Which then discredits the whole basket at once.
So I'll just say it: The typical techie will probably be happier using an editor/IDE other than Emacs.
But it's important for our field and broader society that most techies learn and care about those other ideas.
Lots of talk about "fiddling with configs" here, but in my experience it's like a slow evolution over time: you adjust things here and there as you need them. That's a malleable system. It's not a constant tinkering, but a willingness and ability to adjust as you go.
AutoHotkey enables Emacs-like extensibility at the OS level rather than the application level. Some of my macros and shortcuts apply in every text field I interact with, even this comment field on Hacker News. Whether I'm editing in VS Code or vim or Microsoft freakin' Notepad, my macros travel with me. I like that a lot better than being locked into any specific editor and unable to get comfortable outside of it.
I can't ever imagine switching from vi at this point. It's what I know and matches the unix philosophy of do one thing and do it well. I can easily run shell commands as I need to without it interrupting my work flow.
Why would I switch to something that does everything and has an entirely different workflow? If emacs works for people, good for them, but it isn't for everybody.
Which is totally fair. I kind of despise the Emacs vs Vi(m) flamewars. I like them both. If I don't want to launch a several hundred megabyte program to edit a quick config or something, I'll launch any of Micro, Neovim, or Helix (yes, I like to experiment - side note, I recommend Helix a lot) and that does the job more than adequately. But if I want to work on a big project, take notes, write a blog post or article or document, track todos, check RSS feeds... I personally prefer Emacs.
Remember to contribute money/time if you love and use emacs!
Microsoft recently cancelled PayPal for Github sponsors and Tarsius lost significant amounts of income (that was already below minimum wage)[1].
A small contribution, the price of a coffee a week, which for successful developers is very little, goes a long way in supporting open source that doesn't have extensive corporate support like chromium/linux/docker.
Same, but with doom instead. It has a sensible set of defaults and easy ways of installing packages. I haven't declared config bankruptcy since moving to doom.
I tried Doom but I didn’t liked the fact Vi keybindings where enabled by default and the workflow tries to mimic modern Neovim setups. As an old an old Emacs user it felt atrocious to me.
1. The initial setup lets you choose if you want vim keybindings or emacs.
2. The workflow does not mimic "modern neovim setups". It defaults to hlissner's preferred style, which predates neovim, but is extremely customisable. I mean, it's emacs, after all.
3. Hating on "neovim style" as an emacs user is something you and I better than. We are both old emacs users; we can customise emacs however we like.
4. I was an emacs user before Doom Emacs. I still found it a great as a starting point and ported over my customisations on to it. You don't have to use Doom, but you can, if you want to, and still have your emacs how you like it.
For code, I use JetBrains IDEs (CLion, IntelliJ IDEA, PyCharm, Rider). They are incomparably better than any editor on Earth.
To edit large text files, I use Vim, as it is one of the fastest editors I've ever tried.
For anything else, I use Emacs: scripts, programs written in languages with no good IDE support, personal notes (Org mode is awesome!), handling of Git repositories (Magit is better than JetBrains IDEs), email (Notmuch). If only it could be made faster when editing large files…
You remind me of that anecdote by, I think, Tyson (the astrophysicist), who gave an example of a person going to the ocean shore with a cup, poring some ocean water into it and swiftly concluding that there aren't any whales in the ocean based on what they saw in the cup.
I mean, you are in no position to judge about good editors on Earth... you haven't worked with good editors yet.
This is evidenced by your gripes about editing large files. Emacs may be configured to be used as a pager for Christ's sake! It can work with whatever file size you have. If you don't know how to do that, that's a you problem, not the editor's problem...
If you haven’t yet developed your emacs muscle memory I would suggest remapping your keyboard to swap the left-control and caps-lock keys. Your pinky will thank you.
In macOS you can do this by going to Settings->Keyboard->Keyboard Shortcuts->Modifier Keys.
If you haven’t yet developed your Emacs muscle memory, consider taking a look at Evil. I switched about 7 years ago after well over a decade of using the default Emacs text editor. It was the right move. VIM IMHO just is a better editor. Emacs is the better everything else, but thanks to Evil, you can both eat this cake and have it, too.
For me, a good stepping stone to Evil was God mode. It strips away the need to mash modifier keys, but retains all the Emacs keyboard bindings. It gives you a glimpse of what using a modal editor is like, roughly, with a tiny cognitive effort investment.
But sometime ago I realized I was adding so many customized code lines to my .emacs to reassemble the modern editors that it made me think I was using it wrong. Then I decided to take a break and start using Neovim, which imo borrows some nice stuff from EMacs like the Terminal and the lua interface.
> adding so many customized code lines to my .emacs to reassemble the modern editors
I feel like trying to recreate vscode in emacs could be a suboptimal approach to say "add a directory sidebar and lsp-mode, but get used to emacs buffer and tab handling"
Why would anyone want to recreate VSCode in Emacs? It's like asking a philharmonic orchestra to play Country Roads... Yeah, they probably can do a very good job at it, but they are there to play some more interesting music, wouldn't you think?
> get used to emacs buffer and tab handling
This clearly shows you've never used the program you are so confidently talking about... What tabs?
There are plenty of ways of managing multiple buffers, and tabs is... just one of them, and, it's just not good... Complaining about it just means you don't understand how to use the editor you are complaining about. These tabs are for people who come from another editor and think they need tabs. Similar to how you can have scrollbars or panels with buttons to do things in Emacs, but they aren't there to improve editing experience, they are there to help the inexperienced to transfer their experience from other editors onto the new one.
There are plenty of ways of managing multiple buffers, and tabs is... just one of them, and, it's just not good... Complaining about it just means you don't understand how to use the editor you are complaining about. These tabs are for people who come from another editor and think they need tabs. Similar to how you can have scrollbars or panels with buttons to do things in Emacs, but they aren't there to improve editing experience, they are there to help the inexperienced to transfer their experience from other editors onto the new one.
> What's the connection?
> Complaining about it just means you don't understand how to use the editor you are complaining about.
I must admit, I'm pretty confused here.
I'm not complaining about tabs?
> There are plenty of ways of managing multiple buffers, and tabs is... just one of them, and, it's just not good
What do you use for managing multiple buffers? Do you not care about distinguishing one projects buffers from any other project?
> These tabs are for people who come from another editor and think they need tabs.
The tabs in emacs are different than the ones in vscode. In emacs terms there is only one window containing one buffer you cannot change per tab.
tab == buffer in vscode
> Similar to how you can have scrollbars or panels with buttons to do things in Emacs, but they aren't there to improve editing experience, they are there to help the inexperienced to transfer their experience from other editors onto the new one.
I used to think this, but my mind was changed after seeing many experienced emacs users that do prefer using scrollbars, buttons, or the new context-menu-mode.
emacs is about freedom in a lot of ways including how you use emacs, not some "ur a noob if you use the mouse" type thing.
> they are there to help the inexperienced to transfer their experience from other editors onto the new one.
People vary. For someone disabled, it's possible that in many scenarios using the mouse is faster for them than the keyboard. So the fact they use the mouse doesn't make them inexperienced.
There is utility in these features and they don't purely exist to bridge the gap for new users coming into emacs.
> The tabs in emacs are different than the ones in vscode.
Just forget tabs exist in Emacs. Like I said, they are for people who are used to have tabs, but serve no purpose if you use Emacs. It's like if you were trying to use Photoshop to run unit tests for some JavaScript code you wrote for Web browser. Yeah, it has a built-in JavaScript interpreter, but really, it's not meant to be used as a JavaScript runtime.
> tab == buffer in vscode
Not sure what you are trying to say... Do you mean a "tab" in VSCode terminology is equivalent to "buffer" in Emacs terminology? -- If so, that's not true. VSCode has a number of fixed windows, which cannot have interchangeable contents. It has a window dedicated to showing text files, it has a window dedicated to interaction with shells, it has a window dedicated to interaction with filesystem etc. While this is really inconvenient and the lack of generic approach is really hurting due to inconsistencies between these windows, that's how they chose to do it.
> I used to think this, but my mind was changed after seeing many experienced emacs users that do prefer using scrollbars
I haven't met a single Emacs user who'd use scrollbars. I probably met about 2-3 dozens. Most wouldn't even know what they look like. Scrollbars aren't well-integrated into the rest of interaction with the program. It's a handicap if you use them. I cannot think about a single reason, a single situation in which scrollbars would be preferable to other methods of navigation. They are less precise, slower and in some cases impossible to implement (eg. infinite buffers).
Freedom and being a noob are orthogonal to each other. I didn't say you should never use scrollbars. I said that if you are a noob, that's what you will likely end up using... I don't say you shouldn't be a noob, I just say that being a noob sucks.
> For someone disabled
And for some who don't have hands, it's even worse... what's your point? There's the reality of text editors: if you have two functioning hands, you are in a very advantageous situation compared to someone who doesn't. Comparing the two doesn't make sense in the same way how it doesn't make sense to let super-heavy-weight boxers compete with light-weight boxers.That's why those categories were created in the first place.
Clearly you are not understanding what tabs in emacs are... it's pretty much a visual way to identify windows-configuration-to-register, and instead of doing C-x r w REG / C-x r j REG all the time you have a nice automatic way...
(please read the emacs manual the other post of this thread as posted)
> it's pretty much a visual way to identify windows-configuration-to-register, and instead of doing C-x r w REG / C-x r j REG all the time you have a nice automatic way...
That's a great succinct way to put my longer elaborate example that's a sibling to this response.
I'm familiar with and have used Helm, Projectile, and project.el. I've also read that Wiki quite a few times :)
>> The tabs in emacs are different than the ones in vscode.
> Just forget tabs exist in Emacs. Like I said, they are for people who are used to have tabs, but serve no purpose if you use Emacs.
That's not true.
I use both Ibuffer and tabs. I effectively use tabs to hold window configurations and project buffers. That means instead of having to pick related buffers out of ibuffer I just switch to tab `proj1` and things are probably how I need them already. I suppose I could use registers, but that seems like more steps.
I'll use this ibuffer state with two projects open as reference for my next example:
MRL Name Size Mode Filename/Process
--- ---- ---- ---- ----------------
[ Default ]
% *Help* 506 Help
* *proj1-eshell* 41 Eshell /tmp/proj1/
% proj1 212 Dired by name /tmp/proj1/
*% *Completions* 134 Completion List
* *proj2-eshell* 41 Eshell /tmp/proj2/
% proj2 212 Dired by name /tmp/proj2/
foo 0 Fundamental /tmp/proj1/foo
bar 0 Fundamental /tmp/proj2/bar
*scratch* 145 Lisp Interaction
*% *Messages* 1697 Messages
*% *Async-native-c... 228 Fundamental
With ibuffer if I wanted to start working on `proj1` I'd need to replace `tab-bar-select-tab` with:
- `C-s foo RET` to open the foo buffer
- `C-x p e` to open the eshell buffer
I don't have to do that if I use tabs because the window configuration was already in that form.
If I had many source files open or some other more elaborate window configuration it's even more unwieldy to not use tabs. Imagine this example scaled up to with `proj1` and `proj2` having `foo2` through `foo6` and `bar2` through `bar6` each visible in a window split 3x3.
Each time I switch projects I wouldn't want to manually recreate that split. I may not even remember it. Even if I created a register I may not remember that I created a register.
However if there is a tab that already contains that window configuration it is unavoidable because that tab holds the context for me.
I don't see any other way to get this functionality without tabs or without me "just remembering".
In case you have some counter-example in mind, it'd be good to work from a common example. Here's the bash snippet I used for the example above:
cd /tmp && mkdir proj1 && cd proj1 && git init && touch foo && cd .. && mkdir proj2 && cd proj2 && git init && touch bar
>> tab == buffer in vscode
> Not sure what you are trying to say... Do you mean a "tab" in VSCode terminology is equivalent to "buffer" in Emacs terminology? -- If so, that's not true. VSCode has a number of fixed windows, which cannot have interchangeable contents. It has a window dedicated to showing text files, it has a window dedicated to interaction with shells, it has a window dedicated to interaction with filesystem etc. While this is really inconvenient and the lack of generic approach is really hurting due to inconsistencies between these windows, that's how they chose to do it.
I meant to express that vscode tabs are more limited than emacs tabs.
>> I used to think this, but my mind was changed after seeing many experienced emacs users that do prefer using scrollbars
> I haven't met a single Emacs user who'd use scrollbars. I probably met about 2-3 dozens. Most wouldn't even know what they look like. Scrollbars aren't well-integrated into the rest of interaction with the program. It's a handicap if you use them. I cannot think about a single reason, a single situation in which scrollbars would be preferable to other methods of navigation. They are less precise, slower and in some cases impossible to implement (eg. infinite buffers).
Scrollbars are the least convincing example of my point. The menu-bar and context menu are much more compelling I'd say. FWIW I don't actually use visual elements at all and just use the keyboard.
I occasionally use VSCode/VSCodium when I want to use a particular plugin like XState but for most of my command-line work nothing works as well for me as emacs shell-mode. I especially like it allows me to search and copy details from command output as easily as I would any other file or data.
But in the past few years I've noticed more and more nodejs and python programs insist on providing "enhanced" output which do not work well in shell-mode. Things like little multi-line progress bars with colors, checkboxes, weird unicode spinners, etc. Most of those depend on cursor motion and ANSI sequences not supported in shell-mode so when I run those I often end up with junk. Setting various recommended environment variables to prevent this rarely works. For example here's what I get if I run a node app that uses a vorpal.js-based REPL in a shell-mode buffer:
Here vorpal's attempt to enhance my terminal experience by colorizing the command I typed effectively ruined my ability to use it in shell-mode. Having to shift out of emacs shell-mode to run these commands is a huge pain but I haven't found a very good solution for this. The ansi terminal emulation emacs provides with things like vterm partially address his but they have their own problems and don't provide the search features shell-mode does.
I suspect few enhanced output terminal CLI developers care about emacs shell-mode users, but I'm hopeful some of them might read this and take a little time to read https://no-color.org and ensure their programs honor things like NO_COLOR, npm config set color false, TERM=dumb, INSIDE_EMACS etc.
Does piping to cat help? That’s one of the first things I do when I run a command that insists on interactive output and I can’t be bothered to figure out what flag to set to turn it off.
I occasionally try that as well and it sometimes helps but not for things like node apps that use https://vorpal.js.org REPLs. They just aren't usable in shell-mode.
Many good comments in this thread. I'll just leave a note of my experience and opinion.
I've used vim since about the year 2000. Before having access to a computer running a Unix, I'd read books about the Unix environment and fell a little in love with ed commands. Their power, yes, but also the immediacy of the user experience. It's just there, all the time, in vi.
Having coded a decent amount of vimscript... Eh. vim is not great (I'll likely never switch to neovim either.) Perhaps the best part about vim is the manual. There are so many features, some of which depend on/affect other features in various ways. I use vim for taking freeform notes, transcribing long form texts mostly - the auto formatting that can hard wrap at textwidth, without any extra command or keypress to trigger the formatting) is a feature I use a lot. The ability to quickly pipe text through Unix filters (mostly `par' in my case) is also great.
All this is easily done in emacs too, but I feel there's more immediacy in vi (and vimscript).
I salivate at the better unicode support in emacs, and the ability to have frames - separate GUI windows of the same emacs process. I would use these all the time. (g)vim likely won't get better in these areas within my lifetime.
Availability on mobile devices: I use an iPhone - it's from work, I have it with me all the time. I do not want to carry along any other device. A recent-enough version of vim is available in the AppStore as iVim. This has become the only note-taking app I can bear to use. It can write to text files on iCloud and access them later from other devices.
On vi clones - I wish Thomas Dickey's editor (vile) had become popular, instead of vim. Proper lexing and parsing for syntax highlighting (instead of regexp soup) - Imagine! I started out on computing with Red Hat Linux, where vim was installed by default - and most documentation, online resources, might have mentioned vim instead of any other clone, leading to vim gaining mindshare.
I find Emacs is great for development and documentation. I tend to use vim only when I need to do a lot of column editing. I was almost 100% vim with a smattering of Emacs. But as time went on I now use Emacs (GUI) much more than vim. I really cannot explain why :)
But I can say git, RCS, etc integration in Emacs is easy and a pleasure to use.
I tried some IDEs a while ago, and they are way to busy for me and required heavy use of the mouse. All I really need for development is tag files, and I was able to find some lisp code that makes Emacs tag handling quite similar to vi/vim.
The only real complaint I have on Emacs is handling of tabs when editing flat text data files. But I get around that by having this:
I started using emacs on and off in the last few years. I’m probably a younger developer than most emacs users, but I’ve always been drawn to the customization and extensibility of it - it seems a generation ago was rich with ways to build unique and customized tools (eg emacs, hyper card). I’ve always liked the idea of living out of the terminal- it basically acts the same locally and over SSH so it’s perfect for working in a highly mobile or portable way. But I’ve slowly realized that it’s basically what a browser is now - just far less extensible and customizable but with far more “modern” and easy to use tools. I wish the browser was the rich and hackable sandbox the next generation of computer users have been missing.
You know I haven’t seen it before. I always assumed that my qualms with the web was the inconsistency (and constant change) of webpages made UI customization impractical. Now I wonder if a different browser would be better at unlocking customization…
I came back to Emacs after trying alternatives for a while. I ripped out most of my config and found it much more pleasant to run close to stock.
I'm having better luck using my web browser for email, sublime merge for Git, debuggers in external programs, etc. If I need to do some edits with multiple selections I open up Kakoune, and if I have a burning need for LSP I switch to VS code.
These days what Emacs doesn’t have can be as important as what it does have. It doesn’t have Chrome bloat. And it has no telemetry whatsoever. Telemetry should be de-normalized. It’s an affront.
One feature I particularly like in emacs is "chord mode". You can bind double keystrokes to features, eg I have @@ to save file. I haven't noticed this available in other editors.
I personally have a set of ⌘N and ⌘W chords [0] for various creations and deletions. ⌘W S to close all saved files is a particular favourite; I don't really pay particular attention to my tabs anymore (just open on the filespace), which is one less thing to think about when coding.
VSCode doesn't have chords. I have no idea why would you link your config to this... Chords are sequences of keys (i.e. this includes releasing keys). Vi(m) do have chords for example though. I.e. a navigation command is usually a sequence of commands that is send to execution after the whole sequence have been entered. This means that the key-binding has a prefix (or multiple prefixes) and will be continued with the suffix. For example, in Vi "dw" is "delete" followed by "move one word forward", where "d" is the prefix and "w" is the suffix. But, "d" may be followed by many other things, all of which will be interpreted as deleting whatever's covered by the movement command. VSCode keyboard interaction simply doesn't work like that. It waits for the single keyboard event (which may involve modifier keys) and then dispatches it to the handler code. The later results in some feedback to the user rather than accumulation of command sequence for later processing.
I work with Windows version of Emacs and works pretty well (c++ with lsp-mode). I'm using Emacs Doom with antivirus disabled. The Linux version is faster than the Windows one, but it's very usable.
The main problem is git, it's slow as fuck on Windows. An operation that in Linux takes less than a second on Windows takes a couple of seconds. Magit is slow on the Windows version, it makes a lot of different commands in background.
That’s weird. I got opposite experience. It seemed that Windows 10 version was snappier than my setup on MacOS. It did feel quirky to work through ecosystem though.
It's like if of all cooking appliances all you had was a microwave oven, and then you complained about not being able to make ice-cream. You chose to play with a handicap, now things don't work well for you? -- Well, guess who's guilty...
i feel you, this is a reason why, even though i started using emacs on the job almost two decades ago, and liked it a whole lot better than anything else i have encountered since, i eventually moved away from it after that job.
the new job was using a language where the source code was in a database of sorts. really fussy about how to handle the code. using external tools was a huge nono.
two jobs later i find myself working with msvs and vscode and eventually realize those are THE WORST tools in existence. well, if you disregard that stuff from earlier...
i returned to emacs, had a hard look at my choices and settled for cygwin. it has its own flaws, but emacs is not one of them <3
now i just need to learn how to use gdb to get rid of msvs for gud xD
nevermind the fact that it was a joke and not a sales pitch, how can any argument make one editor win over another? no argument will change what emacs is or what vscode is.
why do you imagine just saying the windows version of emacs sucks should bring emacs brand ambassadors to you to make their argument for emacs?
It's not a win I'd care about. This takes away the audience which would put a lot of pressure on Emacs developers to do stupid things that would lead to the editor getting worse and worse. This is the "popularity curse" which spoiled a lot of good things in programming world.
So, if people who want to use Windows don't become Emacs users -- I couldn't care less. I don't want these people to swamp the developers with requests to add mouse-based navigation or modal windows. Being few years a dad, I discovered that in situations that don't endanger my son's help, it's more expedient to let him make his own mistakes, if he really wants to, but it doesn't work if I try to pretend that his bad ideas are equally valid as good ideas. In other words, if people want to use Windows, they should be told they are doing something stupid, but they shouldn't be strong-handed out of it.
thats actually my reason for switching away from vscode as im mostly working on machines without a discrete gpu AND utilize the gpu in my projects.. i cant have my code editor use 30% of gpu just to scroll text up and down (without any plugins installed) it's just silly XD
I have to use the laptop that my company gave me. I can't even use the OS I want, I'm stuck with Windows. On top of that, the VPN, antivirus and other garbage running in the background make the laptop really slow. It sometimes take 20 min for it to properly boot and be in a usable state.
That's kinda like a traffic engineer saying "I always get stuck in a massive traffic jam while driving back home. I know, we'll add another lane to the highway."
If a tool runs poorly on commodity hardware the solution isn't "get better hardware," but "improve the tool."
...okay, unless the tool absolutely requires specialized capabilities, like a neural network which needs a dedicated GPU for number crunching.
8 hours battery while doing heavy development on apple silicon hardware, while being the fastest mobile dev machine I've ever owned. Seriously not an issue.
i admire their silicon for its power efficiency, i truly and honestly do.
but i dislike the manufacturers' politics up until now.
if apple ever becomes a beacon of openness, transparency and sustainability: sign me up for the newsletter.
i'll even consider their ridiculous pricetags if apple became comparable to, let's say MNT.
in the meantime im considering to switch my personal laptop over from a T220 to a mnt reform
The tools you work with multiple hours per day and earn a living with should not be "good enough", they should be "best in class". And is a computer that is struggling to scroll in a simple web thing good enough? It's not good enough for your average user who wants to do light web browsing in Chrome, so why would it be good for a developer?
ok. guys? we are (at the extreme) talking about a texteditor here. there is no reason for source code tooling to utilize GPU and if you think otherwise, i have no reason to continue to talk to you :D good day
oh and one more thing:
i assure you, this computer is more than good enough for browsing websites and do whatever you would do as a regular user... idk how you came to the conclusion it was otherwise.
it's not even the case that vscode makes anything slow here, there is no ditch in performance, everything is smooth as butter, i simply report the GPU spiking up to 30% whenever i make vscode scroll text.
are you telling me this is acceptable when i can just as well use a mightier software tool that doesnt utilize the gpu at all?
on another note: how is it be acceptable to anybody to poop a browser into every other new app? element, discord, vscode, you name it, it has electron or whatever in it. i prefer versatile tools over simple ones just like the next person, but i know for a fact: we can have that without all the blingblong.
Market share is not a feature that helps me. A thriving ecosystem and active development is. Emacs doesn't lack either.
Failing to implement UX fad of the moment means that you can rely on the GUI being consistent across years instead of having to relearn it every few months.
But it does show what software is generally better.
>A thriving ecosystem and active development is.
Despite being thriving it still is very lacking in code navigation abilities and has poor performance in general. Not to mention the editor grinds to a halt when working on big files due to extensions being poorly optimized.
>Failing to implement UX fad of the moment means that you can rely on the GUI being consistent across years instead of having to relearn it every few months.
The user experience of a product is much more than just the user interface. Emacs requires you to learn elisp and write a whole configuration file by hand or use really clunky menus.
I agree that Emacs commits a number of unforced errors with regard to its user experience, especially for novice users. My guess is that with some usability studies they could flatten the learning curve substantially and significantly increase their market share with only minimal burden on existing users.
Having said that, "market share" doesn't seem like a relevant metric since the community seems perfectly content being niche.
>since the community seems perfectly content being niche.
This is just admitting defeat. There is no reason Emacs couldn't be the number one editor right now. GNU projects in general all tend to fail to innovate and seem to ignore the last couple of decades of learnings.
> There is no reason Emacs couldn't be the number one editor right now
I suspect you're right that under different stewardship Emacs could have taken over the wold. And who knows, if they cared to run usability studies on the initial user experience it might still be possible.
> This is just admitting defeat
If you assume that everyone values popularity or ease-of-use then this is a reasonable conclusion.
But if you'd forgive some unsolicited advice: assuming everyone shares your values will make it hard to understand or predict other people's actions which will hinder your attempts to communicate, negotiate, or manage anyone not like you. It may be simpler to imagine they're crazy, foolish, or deluded but personally I've found it useful to operate under the assumption that their values are real and just as valid as mine.
seems like you have a bit of an agenda. are you sour about something ? for me emacs is probably the best piece of software i ever used and i use my hardware for everything :|
I'm sour that emacs sucks. I would like to be able to use it for everything, but if I'm being honest with myself other editors simply work better for me.
market share seems like a wrong term for a product that doesnt seem to give an f about it. nor does it seem to care about some mean reversing ui. what it does seem to care about is the users that keep using and loving it ;)
They should care about it. Losing market share means people are finding more value in other editors. Do the developers not want Emacs to give the most value as possible to users?
I disagree that Emacs losing market share necessarily means that people find more value in various editors. While that could be the cause, there are various other possibilities: more people are being mandated the use of various of those editors, those editors may have better marketing, the systems people are using may come standard with editors that are "good enough",...
Use an IDE, you filthy barbarians. There is no substitute for a real IDE when it comes to seamless transition between writing code with full autocomplete support and using the debugger to step through and examine the behavior of that code. And yes, God damn it, you need a debugger. You need edit and continue. You really need structured editing and it's a crime that this isn't available for every programming language, everywhere, in 2023. Modern IDEs give you all these things except for maybe the last in a smooth integrated fashion, and this has been the case for decades now. Using anything else when this is available is like breaking your legs in preparation for the 50m dash. For God's sake, Visual Studio got you 90% of the way to a Lisp machine type dev experience. In the early 2000s, for C++ and other languages people actually use. And Unix weenies still insisted on their stone-knives-and-bearskins tooling, to all our collective detriment.
For languages without robust IDE support, Visual Studio Code will get you most of the way there with the click of a button. Releasing VSCode support including LSP for your language is now table stakes if you want to introduce a new language people will actually use.
You don't need a "real" IDE to use a debugger. A debugger is a debugger, an editor is an editor, a compiler is a compiler. Taping dumbed down versions good tools together and calling it "integration" only ends up with you needing another tool that is not integrated anyways, or you having bunch of tools that you will never use hogging your resources, both computer and brain.
I love it, it’s great, and as many others, I tried to move out of it but there was something I couldn’t do I KNEW I could get in Emacs and it frustrated me so much I kept going back.
But I don’t think it brings a lot of added value. There are many very very powerful IDEs and editors which offer out of the box great UX and feature discoverability. Hell, probably if IntelliJ toolset would allow me to customize it deeper with Lua/Lisp/JS/whatever I’d probably switch in a jiffy.
I compare Emacs to vinyls or paper books. It requires investment, in many cases it is worse than competition and requires more energy to just be on par. But it is absolutely lovable. Vinyl record comparison - they are expensive, heavy, require a lot of maintenance but for specific type of people it makes their heart skip a beat when they take it from the sleeve.
That’s why people are constantly talking about their Emacs. Same with vim or nvim. I rarely hear people talking with excitement about WebStorm or VS code.
So yeah, if you’re not into it just keep in mind that like some freak who spend their weekend on polishing rims of dream come true 1959 Fiat 500, some of us spend their time with Emacs.
Don’t get bullied into it, don’t get FOMO about it, but please don’t spoil our fun.
You’re always welcome to join in.