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
