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.
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.
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.
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.
What I'm objecting to is the very idea of a highly customizable editor.
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.
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.
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 :-)
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.
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 have other, more interesting things in life.
https://micro-editor.github.io/index.html
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 :-)
Also, xkcd is always very poignant:
Software devs routinely fall into this trap:
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 :)
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 :-(
(setq vertico-posframe-poshandler #'posframe-poshandler-frame-top-center)
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.
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.
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.
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.
I mean, you could probably run Emacs as part of your CI/CD pipeline, but it would be a bit... weird?
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.
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.
And I agree, a lot of those heavy advocates live in a bubble
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.
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.
The fuq? I feel sorry for your spouse.
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!
Looks like you need to :git gud with Intellij if you really believe it has a crappy text editor.
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.
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).
(And I don't see the appeal of Emacs at all.)
(And I don't see the appeal of Emacs at all.)
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.
requires barely any ram
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.
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.
alias emacs='emacsclient -c -nw -a ""'
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.
Thank you for this! This cracked me up.
> Gotta go fast. Startup and run-time performance are priorities. Doom goes beyond by modifying packages to be snappier and load lazier.
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 think tools should be able to conform to its users' hands, i dont see that in intellij that much...