I think another reason why Emacs is in a second golden age is due to all of the new plugins that have come out in the past 3-5 years and how those plugins have affected Emacs.
For example, Eglot and use-package being part of Emacs core.
Additionally, there's also just many new plugins for the base-level things. I never thought there would be alternatives to completion frameworks like Helm or Ivy, until new ones came out. It's all been very exciting.
I don't know what plugins OP had in mind, but for me at least, a bunch are usability improvements that make the Emacs environment easier to program. use-package, for example, provides a nice way to programmatically install and configure all the plugins you need. My emacs file config file now is self-bootstrapping - I drop it on a new machine, fire up emacs and everything is there and configured as I like. You could do this before, but it was more work and I had never bothered previously.
Someone else can tell you about Magit (the gold standard UI for Git), or Org Mode (the best markdown alternative / journal / planner / TODO / PM software, if only more people used it...). I want to take a moment to comment on:
> many new plugins for the base-level things
GP mentions Helm and Ivy. These "completion frameworks" are editor-wide, full-blown rich and ergonomic UI enhancements, each with its own philosophy. Each one is an island though - you have to buy into their philosophy wholesale[0]. At some point, however, the community identified the various paradigms and patterns in those completion UIs/frameworks, and where they map to existing core Emacs ideas, and a new breed of libraries were born - Corfu, Vertico, Embark, and many others, each of which provides a single piece of the equation, and deeply integrates into built-in Emacs APIs whenever possible. As a result, you can now mix and match those libraries to replicate something like Helm or Ivy, that works better, is more flexible, and more friendly to code against.
This is perhaps less interesting for casual users, but it means an important philosophical shift in community, towards more targeted and composable plugins. For casual users it just means more powerful, stable, better cooperating plugins.
--
Okay, I lied. Let me talk about Org Mode. My favourite little feature, which I miss from literally any other software I'm using (like Microsoft's To Do I've been using lately for ad-hoc personal things[1]), is `org-extend-today-until`. Made by and for people like me, who always find themselves reviewing plans after midnight, it's a variable you can set to make Org Mode extend "today" past midnight. See: http://doc.endlessparentheses.com/Var/org-extend-today-until.... I set mine to 3 (as in 03:00).
Flexibility of Emacs means people just implement random stuff like this in the first place - features not relevant to Minimal Viable User, but very useful for a subset of users.
--
[0] - Though in Emacs land, this just means it's only tad more annoying to extend, modify or repurpose pieces of those frameworks.
[1] - Org Mode is the bestest, but still has so-so mobile support; currently MS To Do is just the least annoying tool for private planning on the go.
Now mark them as TODO items, with one being in-progress:
* TODO One ..
* TODO Two ..
* INPROGRESS Three ..
In Emacs you can then view your calendar, or org-agenda, which will have the current day and all items on it.
You can add a deadline to an item, and it will jump to that day on the calendar/agenda.
Can you keep track of simple items in google docs? Absolutely. Can you make them appear on a google calendar? No. (Yes I realize Google has todo-app, and that does. Even with recurring scheduling, but that's not tied in to google docs either)
Easy examples, any source that is delimited with `#begin_source language` will have whatever the editor would do for `language` in the delimited section. Searching the file is exactly like searching any other file. Committing it to source is trivial, as it is a somewhat normal text file.
That last actually shows how emacs can be treated like what a lot of folks use jupyter for. With the main difference that the "on disk" form is a somewhat normal text document using fairly trivial markup.
Eglot and use-package allow Installing packages from source, allowing you to easily switch between bleeding edge, tagged versions, and contribute changes.
In this deeply nested Reddit comment, when someone said: "Imo emacs shines when editing, not writing.", I tried giving a few practical examples of how I use Emacs for writing plain text. I'm just gonna list the use cases without specifics, you can click the link below and find details of each package if you're interested. Note that this is a single aspect of things for which I use Emacs. Many other possibilities are abound.
Emacs is incredibly incomparable for writing. I don't even try to type anything longer than three words in anything else. I always try to find "edit-with-emacs" feature wherever I go - I built one for Mac, then I wrote one for exwm, then I did the same for stumpwm . I recently started using AwesomeWM, and now I have it there too. If I'm ever forced to work in Windows, I can promise you, finding a way to edit with Emacs would be the very first thing I will try to solve.
When I'm typing in Emacs, I have:
- Spellchecking. When I mistype the previous word, I would just tap the comma twice, and it autocorrects it. If I need to actually insert comma, I'd use comma and space (which I always do anyway)
- I have thesaurus.
- I have Google Translate, for which I don't even have to switch the keyboard layout, meaning if I want to translate from Russian, it would automatically switch the layout to 'ru' and back to English when it's done
- I can check the etymology and definition of any word.
- I can count the number of sentences, words and characters.
- I can keep an eye on my writing with writegood-mode, it can look for duplicate words and use of passive voce, and perform Flesch–Kincaid readability test.
- Until recently, I was using Grammarly to check the text, these days I simply send it to chat-gpt, and it even shows me the diff upon completion.
- I can toggle "distraction free, zen mode", for writing.
- I can launch a web search on any selected text.
- There are various ways how you can preview the markdown.
- You can write helpers like wrapping a region in a collapsible section, or create "code sections" without any hassle.
- You can edit the code sections in their language environment, with syntax highlighting and REPL.
Eglot is a package that works with LSP (Language Servers). There is another one called lsp-mode.
Eglot is integrated within Emacs over lsp-mode because it was specifically made to use existing hooks that Emacs has.
What this means is that you'd use the base Emacs command for finding a reference, and Eglot will populate the source for that command.
Whereas with lsp-mode, it has it's own command you'd run for finding reference. I do think you could also write code to have lsp-mode populate Emacs commands.
That being said, my impression is that Eglot has better integration with Emacs - which is why it became part of Emacs core.
(It's been a while since I've reviewed the Eglot vs lsp-mode discussions, so anyone feel free to correct me).
Use-package is a package for setting up your Emacs configurations. It allows you to place settings for individual packages in nice little sections. It's mainly used for organization but you also gain a plethora of options as well, like deferring to load a package until you open a file that requires it.
You also don't technically need to configure Emacs by hand by writing code lines. You could always do M-x customize and change settings that way. Emacs will auto-generate code from that and place it at the end of your configuration file.
That being said, this becomes quite messy to look at - so people prefer to use M-x customize to find the setting they want, and then they write it by hand in their config.
A big usage of use-package that I love is that you could specify specific settings that tell Emacs to enable it through M-x customize. If you don't know what I mean by that - that is totally ok. You'll learn about this more if you ever dive into Emacs and want to configure your own settings.
So, I went and took a look at Spacemacs, linked from the original post.
I guess you're supposed to have some version of Emacs already installed? Because the "Download" doesn't appear to include a binary, and the "Installation" just appears to set up your ~/.emacs.d/ folder.
Funny, I presumed that an "Emacs Distribution" would include Emacs.
Yes, you need to install Emacs. It is probably available from whatever package manager your system uses.
I prefer Doom (https://github.com/doomemacs/doomemacs) to Spacemacs. However I haven't looked at Spacemacs for many years; perhaps it's now on par with Doom.
An OS distribution is a whole OS because you need an OS. An Emacs “distribution” (quotes) doesn’t include Emacs because you can already install vanilla Emacs yourself.
It's a fair point IMO. Especially with something like Spacemacs, which really presents a fairly radical different experience to vanilla. I'm not sure anything is really gained by NOT including their own Emacs binary. I guess Emacs doesn't break external code that often, so it might not be a huge issue, but I can't imagine there is never a version mismatch that leads to unnecessary user confusion.
I also see close and almost unbreakable relation between clojurians and Emacs. I always tell them to snap out of it and stop wasting precious company time on configuration and writing + as the first character when doing an addition. When I get serious they always see the light as they convert to python + vim.
Many years ago, I was writing Clojure for a job and took to finally learning emacs beyond just saving a file and closing the editor.
It took about a week to finally get used to paredit-mode (and rainbow-parens, because…) but once I did it is the most productive I have ever felt, I keep trying to find that experience again.
Unfortunately the dynamic types and slow build system (lein) made the build step quite tedious (this was 11-12 years ago) - but in terms of expressing ideas, man - paredit + lisp style was amazing!
I think it's not sarcasm so much as it is gentle self-chiding. Emacs configuration can certainly be a timesink, especially if you enjoy it.
That said, it's pretty easy to put your Emacs config on the back-burner for a long time once you have things how you like them, and it becomes a much more OPTIONAL time sink at that point.
Using something like Doom Emacs could even prevent it from really ever being much of a time killer, but in my experience, once one is bit by the customization bug, one doesn't -mind- the time sink so much because the fruits of your labor are worth it
> That said, it's pretty easy to put your Emacs config on the back-burner for a long time once you have things how you like them, and it becomes a much more OPTIONAL time sink at that point.
To illustrate this, I'm a heavy emacs user. I've been using emacs more or less exclusively since 1999 (I had two years where I forced myself to use vim to make sure I'd really given it a fair shake), including org-mode, using gnus for my email client, and writing code pretty much every day (with magit, helm, and projectile, tramp for working on remote servers). Here's:
~/.emacs.d <master> » git log --pretty=format:"%h %ad %s" --date=short|head -n 20
6795c07 2023-12-23 rust-mode
dd241ec 2023-10-24 full screen automatically on mac
1cf8287 2023-10-22 mac stuff
bc1e456 2023-10-22 conditionally set home dir
e7d3577 2023-10-22 mac font size
f8ba89c 2023-10-22 add ligature stuff
7ef9bce 2023-10-22 add ligature.el
1aaf1e1 2023-05-06 gitignore some stuff
de56154 2023-05-06 update the other capture template entries
948d2ea 2023-05-06 capture template works differently now
5b2d34e 2023-05-06 copilot
00991ae 2019-12-28 whitespace
d334506 2019-12-28 don't need the other conditional either
95ffdf7 2019-12-28 still working
23378b8 2019-12-28 oh... working now?
c1fb771 2019-12-28 that works fine again
caf80c0 2019-12-28 removing recenter seems to help
04eba58 2019-12-27 setup
171f175 2019-12-27 weird
05c4163 2018-03-14 terraform/hcl mode
20 commits in the last six years. A good chunk of them because I got a Mac last fall (for work) and so I finally had get my config working somewhere other than Linux. Mostly I only have to tough the config when I add a mode for a new language or when I go through a major OS upgrade that pulls in a new enough version of emacs that I need to make some fixes. I would say that none of those took more than 5-10 minutes of my time. I have about 100 commits total in my git history (so going back to about 2008). Meanwhile, I see colleagues using VSCode constantly trying out new plugins and configs. I think I've spent more time in pairing sessions in just the last year watching other people tweak their editor settings than I've spent configuring emacs in the last decade. When I get a new machine, I just clone that config repo and I'm good to go.
I want to love emacs I really do. Couple things that I really get hung up on
MELPA isn't user friendly - I don't mean in the usability sense. The maintainers routinely remove packages that are being used. Breaking your end-user's dependencies for non-security related reasons seems unusual for a package repository. If it goes into MELPA and a user has downloaded it, it should stay there for basically forever or as long as feasible.
Performance - emacs is noticeably slow even on latest Apple hardware and I can't seem to get to it to an acceptable performance level. The bar for acceptable for me is VS Code.
- "Performance - emacs is noticeably slow even on latest Apple hardware and I can't seem to get to it to an acceptable performance level. The bar for acceptable for me is VS Code."
Is it plain Emacs that's noticeably slow, or Emacs after installing 3rd-party packages? Some of the popular ones are very performance-costly.
before native compilation Emacs itself was pretty dang slow on its own, and you probably have to compile yourself to get nativecomp (which won't always be true) depending on the distro you're using etc
nativecomp is pretty much a gimmick and should make absolutely no difference in perceived Emacs slowness during actual usage and not stupid microbenchmarks.
Really? Do you have any links to explain this? I find this to be a super unintuitive result because I would expect compiled code to be faster than interpreted. My recommendation for native compiling is just based on personal experience not benchmarks. Emacs feels faster after enabling it.
> nativecomp is pretty much a gimmick and should make absolutely no difference in perceived Emacs slowness during actual usage and not stupid microbenchmarks.
That is completely wrong. I'm using Emacs back since when I was compiling it on 486 with 8 MB of RAM. nativecomp is the single biggest speed boost I saw Emacs ever getting. Using Emacs on the same machine with nativecomp on or not was night and day (a Core i7-6700 in my case: maybe the difference would be less noticeable nowadays but I couldn't tell as I now only ever run nativecomp and compile it with nativecomp on).
You're the first person I ever hear saying nativecomp doesn't make a difference.
well, it does make a difference in the perceived slowness, so something about your mental model of what nativecomp does, must be incorrect.
I compile Emacs from source specifically to get nativecomp because of the obviously perceptible difference in performance. Maybe you have a much faster computer than the rest of us?
Everyone that recommends nativecomp as a way to fix perceived Emacs slowness in this topic is basically parroting something that's completely and utterly wrong. Native compilation should make no difference in perceived "slowness" for the vast majority of real-world use cases.
I'm curious why you think that? Certainly "use your faster computer" is more impactful, but I definitely feel things are a bit faster with native enabled.
Run 'emacs -q' (no add-ons loaded) and it should be a lot faster than VS Code. Which means that a library you loaded is the culprit. Things like Doom Emacs are notorious for unexpected slowness since they're not very well put together and load questionable libraries.
Hmm. I have quite the opposite complain. Why is when I install a single extension that enables Vim navigation in VSCode there's quite noticeable typing latency? And it's not a single plugin, I tried multiple. While my Emacs instance where I use over 300, built-in and third-party packages still feels quite snappy.
I'm not saying that Emacs built in such a way that it is impossible for a package to degrade its performance, that can happen, but if you know how to use the built-in profiler it's not that difficult to find the culprit and either remove it or try to find a workaround.
While typing this comment I googled, TIL - VSCode has very impressive Perf Tools suite for profiling. That makes it even more surprising, why would the authors of those Vim plugins, and I'm not talking about some obscure and esoteric thing, but supposedly popular, demanded feature, ship it with such obvious deficiency?
Observing this latency after adding just a single extension, frankly makes me question the long-term viability of using VSCode as my main code editor.
Well vscode is vscode, vim is vim. Don't get me wrong, I use vim a lot and I tend to use macros as a rudimentary text automation language. And I use it all the time on servers, because its universally installed. Mixing these things is pointless because you are fighting both and getting nowhere.
Learning vim definitely has its use.
But both vim and emacs have lost the code tooling wars long back. You can configure emacs and vim to to anything. And that is not a win vim/emacs users think it is. Nearly all the programmers out there don't want to spend time on sub projects, just to bring their tools to bare minimal working standards modern tooling provides out of the box. vscode just works, it works out of the box, for 99% of the use cases out there and it works phenomenally well.
Plus the whole idea of being able to write out code faster, or navigate faster made sense in UI paradigms of the old, where there were no windows, and a overall better UI experience. These days coding and navigation speed aren't even in the ballpark of factors that slow me down as a programmer.
And yeah, Org mode. Unfortunately Google docs do way more, and you don't have to remember dozens of commands to just make simple tables, add dates and bullet points.
In many ways Richard Stallman had an idea that emacs should have really had a WYSIWYG facilities. But Google Docs go even one step further as everything is saved on a cloud and you don't really have to worry about losing anything at all.
Emacs on the other hand is a great time pass hacking tool, if you are bored or just want to work on something cool.
Ah yes. Those very precious programmers, who can’t be expected to configure a non-proprietary tool, because they are too busy making another dopaminergic app at their corporate job. The medium is the message, I guess.
Every single tool has problems. There's no application that has no bugs, no limitations. There's nothing wrong with wanting to use specialized tools to perform specific tasks and most people choose to do that.
The main point you're missing is that at some point in your career, inevitably, you'll collect so many tools in your toolbelt that you might become overwhelmed.
There are tools for debugging, searching, formatting, converting, documentation, device control, synchronization, networking, databasing, containerization, security, etc.
Most tools operate with data. And most of the time that data doesn't stay in the context of the same tool - you have to pass it somewhere else. The common approach of unexperienced devs is to become "a copy-n-paste programmer". No, not someone who grabs the code from StackOverflow. I don't know if SO has much value in 2024, I stopped using it a source of valuable knowledge long ago, I do occasionally find clues there, rarely complete answers, perhaps the complexity of my questions has changed, but I'm going off the rails here...
So, anyway, at some point you'd become more efficient in enabling tools to exchange data. Experienced Vimmers use terminal tools with piping, etc. Some of them develop really neat and powerful mini-automation workflows.
Emacs is another amalgamating medium that can be used for the same purpose. People with shallow understanding of Emacs often get grumpy for Emacsers wanting to do "everything in Emacs". Matter of fact, it's not about doing everything in Emacs, but rather doing everything _through_ Emacs. And that can be quite effective too.
So tell me, why is it so difficult for you to accept that Emacs is just another tool, not a replacement for some other specialized single-purpose tool, and that it is quite good at what it does - that is to work as a "glue" to orchestrate many other tools?
Maybe VSCode is truly better in that aspect than Emacs. I don't know. I have yet to find out. So far, people have been claiming that it just works better as a code editor in specific languages, but I haven't heard it being used as a "tactical unionizer" that can talk to many other tools in a way that Emacs does.
I honestly can't deny or approve this message because I haven't yet used VSCode extensively. But I have used many "phenomenally good" tools in the past. Borland stuff in the 90s was fantastic, MS Visual Studio in 2010s had some awesome features, IntelliJ IDEs today are amazing.
Over the years I've developed a distaste for proprietary products. Not because of money, it's rarely an issue. I happily paid for using IntelliJ products, even though I don't use them anymore, I still believe that they were worth every penny.
Perhaps it's debatable but the price for using Photoshop maybe is fair. Photoshop is a truly exceptional tool in its own category. I don't know any other tool that comes close, proprietary or open-source. Photoshop is the most creative graphics tool. But that's my opinion of an occasional, amateur graphics designer.
The reason for my distaste for proprietary tools for professional programmers is the lack of freedom to tweak, the right to repair, whatever you call it. I firmly believe that programmers should be able to program their tools.
Again, maybe VSCode already is as darn hackable as many people claim it to be. From my limited experience, I got the feeling that today it lacks some extensibility capabilities I'd like to see. But it's evolving fast, the pace of its development is quite impressive. Maybe in a few years, it could truly be crowned as the most hackable devs tool that outshines even Emacs. For me, Emacs is like Photoshop for programmers. It's the most hackable software product that you can tweak to perform any kind of crazy shit. But again, that is my opinion and a lot of people maybe would disagree.
Maybe Google Docs gives you the satisfaction and feeling that it lets you do more, not for me.
- Google Docs doesn't have vim navigation and I need that in my editor. Trying to convince me otherwise is like punishing a child for being born left-handed.
- Google Docs cannot handle my pdf annotations, I can't read a book while simultaneously taking notes. I mean I can, by having them in separate apps, but I won't be able to jump to the page from my notes and vice-versa. I can do that in Org-mode.
- In Google Docs I can't have code snippets that perform computations. I can't send a http request, then get the results and feed them to some Python, process that data through Clojure and spit out a diagram in .png. I can do this in a single org-mode document.
- I can't keep my Google Docs Zettelkasten-style, similar to Roamresearch, Obsidian or Loqseq. I can do that in Org-mode.
- I can still use Google Docs and link them from my Org-mode documents, I can't do the opposite.
- While typing in Emacs, I can automatically correct my previously mistyped word by tapping the comma twice. I don't think anything like this even remotely possible in Google Docs.
- I can fetch a definition, list of synonyms, etymology, translation of any word with a single, simple keystroke while I'm writing text in Emacs. I don't know how to do that in Google Docs.
- I can select a region of text and feed it to ChatGPT, asking it to fix mistakes, rephrase, simplify, etc. In place. No copying, switching, pasting. I simply select, press a few keys - voila. It even shows me the diff of what's changed.
- I can't encrypt my documents with my GPG key in Google Docs. I can't store my docs in a git repo. Even though Docs provide a great way of restoring and tracking history, I don't think it's grepable. Org-mode and Emacs manage my documents in git with git-auto-commit-mode, without my supervision.
- I can't easily export my Google Docs to Anki. My anki cards are stored within my notes - they are not separate entities that I have to manage in a different app.
- Google Docs can't manage my dotfiles. All my config files for zsh, bash, command-line tools, package-managers, etc., all kept in a single Org-mode document. Literate p...
I wouldn't go so far as to call native-comp feature a gimmick, but you probably won't see noticeable UI performance improvements with it. On the Mac, --with-metal support may give it a bit snappier feel but it depends on the hardware, you may try both, with and without and compare.
Matter of fact, Emacs with native-comp flag may give you an impression of things being super slow right after the startup, because it often has to recompile packages asynchronously, the process of which you can observe in *Async-native-compile-log* buffer, it's normal for Emacs built with native-comp to be a bit laggy for a minute or two at the startup, but you don't have to restart Emacs very often. native-comp benefits can be observed when using things like lsp-mode, where it brings some good perf improvements, sometimes it's worth it, but you also have to expect things to break, and quite often, native-comp relies on libgccjit, and MacOS updates often break the toolchain dependencies, and it can be highly annoying if you like to update Emacs packages often, especially when using something like Doom or Spacemacs, but it's not Emacs' fault. It's great that we have the option to disable native-comp completely without having drastically reduced performance, most of the time, you won't even notice it.
Also, one thing I always recommend doing on the Mac, which is absolutely unrelated to Emacs is this:
```bash
# "Set a blazingly fast keyboard repeat rate, "
defaults write NSGlobalDomain KeyRepeat -int 1
# "Set a shorter Delay until key repeat"
defaults write NSGlobalDomain InitialKeyRepeat -int 10
# disable accents on key hold
defaults write -g ApplePressAndHoldEnabled -bool false
```
Reboot after setting that and trust me, you'd thank me later. Emacs would feel like it's on steroids. And remember, don't ever change repeat rate in Preferences dialog, it resets it to the values acceptable for muggles. Don't be one, be the keyboard wizard, let your machine fly.
Doom Emacs actually compiles your packages ahead of time before your editor even starts, which is a dog slow process to go through when you do it, but you only have to do it once and then your editor is as snappy as you could want. My Doom (which has a lot of layers enabled) starts in 0.17s iirc
AFAIK Doom Emacs is either already switched to async compilation or in the process of moving that way. So it shouldn't be pre-compiling the packages anymore or that's the idea. I wasn't closely following the discussions around it, so I don't know the exact specifics.
Async compilation does not slow down the startup time, it's not what I said. My Emacs instance also starts very fast, that is a signature feature of Doom. But do check your buffers, there will be *Async-native-compile-log* there.
What I'm saying is that when you start it, while it's running compilation asynchronously you may feel some slight, almost unnoticeable (or super noticeable - it's subjective) UI performance dip, it's not a big deal.
I switched from VS Code to Doom Emacs last year (I had been using Spacemacs before that) and my Emacs is infinitely faster than a similarly configured (homologous extensions, etc) VS Code. So I suspect it might have something to do with your configuration?
* make it fast (magit is the benchmark, if magit becomes fast emacs is fast, for those who dont know magit is slow, very very slow)
* add more UI stuff (graphical tree browsers, tables , etc ..)
the core concepts and main UI of emacs are the best there is in my opinion, simple, uncluttered , logical
curious if you're using nativecomp or not? magit does not seem slow to me and while I do use it on real repositories I do not use it on any insane monorepos or anything like that
I find emacs moves plenty fast for my human brain. Including magit, anything to do with git slows my brain to a crawl anyway.
I get that it might be slow if you're trying to use it to automate something complex, as some part of a server, etc. but it more than keeps up with me.
Then the slowness that you're seeing is probably Windows-specific, and that's why everyone else is telling you that Magit is actually fast.
WSL might make things faster.[1] IIUC, the problem is that starting new processes is much slower on Windows than on Linux/Unix and Magit relies heavily on that. This seems to have plagued Git tooling more generally but maybe this got fixed since then.[2]
Magit is plenty fast for me personally. Near instant even. As for UI stuff, I'm not sure what you mean — it does have a file tree sidebar minor mode, and it can display images and tables and so on in Markdown or Org
yes things like the tree sidebar, i think those UI element can be improved, again magit can be used for benchmark, this can improve the log viewer make it look nicer
Magit is not slow. At least the components that make Magit are not slow. transient, magit-section, forge, etc. are not slow. Magit delegates things to Git, and that can be slow in certain cases on specific environments. Learn how to use built-in Emacs Profiler to find things that make it sluggish.
For example, Magit tries to display tags (in addition to branches) in the refs buffer, for the project that has too many, yeah, that may be slow. The solutions is simply to remove the hook
It's just a single, isolated example. People complaining "Emacs is slow", is like choosing to drive a nail with the handle of a screwdriver and complaining how hard that is. Well, maybe learn how to use the tool, no?
Emacs is a Lisp machine made to run Elisp byte-code. It's not a final product built with some C and Elisp that you may never need to learn. You do need to have at least some basic understanding of Elisp.
Even if someone is impatient, they could develop inner curiosity and type in ChatGPT "what happens when Emacs opens a buffer". Basic understanding of standard hooks and hooks in general, advising functions, etc. is all required for you to be the "user of Emacs". No wonder we see people claiming to have used Emacs for over a decade and still switching to VSCode. Turns out, most of them never wrote a single Elisp package, or ever understood how some copy-pasted magical elisp snippet ever worked. I can't claim to be a chef or even good at cooking if all I ever do is microwave pizza. Even if I did that for twenty years.
I'm not saying that everyone using Emacs should know how to setup Gnus, master keyboard macros or should be able to whip up a new minor mode in zero-gravity. But please try the built-in Profiler. Learn how to use describe-command, describe-key, etc. It is not that difficult.
LSP is basically an open(-ish) source implementation of Google’s internal tool called Grok. Grok was made by Steve Yegge, a formerly famous tech blogger. Steve Yegge uses emacs, and half his motivation was to equalise editors by moving the language processing elements to an external place that’s shareable by all. He has a great talk on it: https://youtu.be/KTJs-0EInW8.
So it’s, like, not an accident that emacs can leverage this :-D. Though I never see anyone giving him credit.
> Steve Yegge uses emacs, and half his motivation was to equalise editors by moving the language processing elements to an external place that’s shareable by all.
That is cool. I was thinking just today (without knowing it was the intention) that LSP has meant I moved from an IDE to an editor with plugins (Kate, not Emacs), because an editor now has so much more of what the IDE can do.
js2-mode was the coolest major mode for Emacs back in the day. The js2 parser is primitive, non-incremental and language-specific.
semantic-mode almost, a-a-a-lmost did something similar (mostly based on LR incremental parsing) but was Emacs-only and never gained enough traction.
Tree-sitter is decades ahead of both. It's hard to compare js2 to a modern GLR incremental parser generator of Tree-sitter. I am not even talking about the size of the community building grammars useful in all the editors out there.
I'm somewhat amused by the idea that this can be traced to a single tool. Cscope and simple ctags predate both by a long shot and were similar ideas. SLIME and SWANK were similar ideas that have also existed for a while, at this point.
Which is not to say that Yegge and others haven't created some nice things. They have. I tend to see it more that they succeeded at problems previous people had either failed at, or had a much more limited success. Progress is not always new things. Nor is similar effort always informed by each other.
That is an obscured perspective. Yes, learning a skill takes time. Mastering a tool requires patience and time. Developing intuition, sharpening your instincts and gaining insight takes time.
Software development is a multi-faceted discipline. There are many different ways to become good at it.
The ultimate goal is not only achieving excellence in productivity but also gaining perspective on remaining happy.
The most important medium through which we convey ideas, information, and even emotions is text. Often, programmers place a greater emphasis on the formal language of precise and structured nature of programming languages. They may even become emotionally attached to a single programming language. Notoriously, most people overlook the importance of plain, simple, unstructured text. The value of taming the wild nature of plain text (even before programming languages) is underestimated.
Find Graydon Hoare's post "Always bet on text", it's revelatory.
There is no equivalent in any other communication technology for the social, communicative, cognitive and reflective complexity of a library full of books or an internet full of postings. Nothing else comes close.
One can spend many cycles learning tool after tool, jumping from one to another, newest, shiniest, "most innovative" thing that comes out, in attempt to find the most effective way, most productive way, most delightful way to gain power over text.
I myself spent years trying things like Evernote, OneNote, Google Keep, Notion, Workflowy, Apple Notes, Zoho Notebook, and countless other tools.
There were always some factors that made me switch. Initially I decided to learn Emacs, thinking it's just another code editor. It took me quite some time to master it to the point that I can now bravely try to implement some wildest ideas. I came for a specific tool for coding, instead, I found a world of incredible possibilities to manage text, any text, not just programming. All my notes, all my writing, my browser history, retrieving YouTube transcriptions, Anki cards, pdf annotations, emails, rss feeds, and of course, coding, all that I do in Emacs.
Why? Because it is not only extremely powerful and allows me to be immensely efficient. It also gives me enormous pleasure, allowing me to perform things my way. If frustration could be measured in wasted fiscal expenditure, Emacs would've saved me quite significant amount of money.
Yes, that long-term satisfaction and liberating power were not granted to me. I had to spend many hours, days, and months of learning until I felt empowered. But that is a lifetime investment that is unlikely to ever diminish. Even if Emacs itself becomes obsolete, the mindset it helped me develop will remain. I will never be the same again. No other highly specialized tool will sway me to pay for it or waste my time, unless it is as extendable as Emacs. And there's nothing today that comes even close. Anyone who says otherwise either doesn't know the limitations of their tools or is unaware of the capabilities of Emacs.
When I started using Emacs about 25 years ago and 20 years ago started using it professionally, _everybody_ used it to program on Linux - yes, I have had two colleagues who used Vim and Kdevelop, but apart from these two goofballs, everybody used Emacs (for C++). I even paid for Xrefactory https://www.emacswiki.org/emacs/XreFactory 20 years ago.
Now? There is one left (yes, I switched to VS Code :() who still uses Emacs and there are even more Vim users (not admins!).
And whenever I read something about Emacs online it's mostly Magit (I don't get that, I either use the CLI or a real GUI frontend) or Org-Mode (not for me either).
I think Emacs users want led the best IDE-like experience they could get in the terminal, while Vim users wanted Vim. As a result Emacs is always fighting a much tougher fight.
(FWIW I like Vim; this isn’t an example of an Emacs fan touting their advanced ide-like editor).
Emacs survived because it adapted. LSPs are the new hotness? Here's the LSP mode for Emacs. VSCode emerged with a massive number of extensions? Here's Doom Emacs with declarative package management. Emacs continues to evolve to face new challenges.
And hey, no editor does Emacs key bindings emulation as well as Emacs itself.
It is nice to know that I am special ;-). Do I get extra points if I told you that I do it all on a custom mechanical plank keyboard with blank keycaps? Of course, I don't use emulation. My windows manager is exwm, so I do everything in emacs.
Emacs keybinds are great. How do you move the cursor up, down, left, and right without them, the arrow keys? My pinky doesn't stretch that far, and if I have to move my hand I'm gonna lose time moving back because I need to find the articulation for my index finger. Vi bindings are even worse: you start typing and the text goes haywire because you're in the wrong mode.
Though in true Lisp development fashion, they solved the easy and shiny 80% of the problem, leaving rest as an exercise to the reader :).
I need to review the current state, but back about half a year ago, when I evaluated them all, I had a lot of "fun" getting them to talk to Azure OpenAI (instead of OpenAI). Or even to allow to override the system prompt. Granted, those were early GPT-4-by-invite-only days, but still.
Still, the most important takeaways are that:
- Emacs community can and does react quickly to any new development;
- Sure, early on the packages may be somewhat half-baked, but it's not that hard to improve/fill in/fix them on your own, with config tweaks and maybe a pinch of simple Emacs Lisp code, even if you barely know anything about programming. That's in contrast to just about any other editor or program, where this is just not possible.
IMHO, Doom without a doubt. It is much cleaner, less buggy, and chooses better packages and configuration defaults in my opinion. It's also even more committed to vim key bindings everywhere than spacemacs is iirc
They all use evil-mode for Vim emulation. So it's just their choice of defaults and configuration style that sets them apart. Doom might have a slight edge with a focus on performance.
Evil-mode is not the only way. There are other approaches like devil you might want to check out.
I think the author is right about some things (e.g., MELPA, killer packages) and less right about others (e.g., GitHub, Clojure, Maintainers).
I personally suspect that the big reason behind Emacs' resurgence is the feeling lately that computing is no longer responsive to user needs. That it's all about designing, and redesigning, and redesigning again, interfaces to make pretty screenshots, with the user being totally downstream and hardly even a factor in the minds of whatever designer has been assigned to work on the product most recently.
Emacs by contrast gives you an ugly interface that cares about function almost to a fault, that you can then make your own. It gives you the tools to look inside what the program is doing and change its appearance, its functionality, how much or how little information it shows, what that information is, etc.etc. All without constantly shifting under your feet, even with the significantly accelerated development over the last few years.
I do have some concerns about that last part to be honest, with Emacs seeming a little too eager these days to add features that seem to violate its underlying philosophy or design, but it doesn't seem like big, breaking changes are happening on the regular, so for now it's still a platform you can develop atop of as an individual, and feel like you understand and can at least partially map out in your mind.
In short, it presents a philosophy and experience of computing that you don't get very often anymore, even in open-source, especially if you're not a fairly advanced programmer already.
I would say that it is also no coincidence that author talks about Clojure as an example - a lisp language, which have obviously great support in Emacs. For the rest of development ecosystem support is of lower quality and now, with the transition between LSP and eglot and the unfortunate way how treesitter mods were implemented, the ecosystem is even more fragmented. I still like some aspects of emacs (configuration on-the-fly), do not care about others (magit, org-mode) but the state of development ecosystem is the true problem for me. Neovim is a much sharper development tool as of now in my opinion.
> Killer “Apps” ... What would you add to this list?
use-package, hands down. my decades old rat's nest of a config actually became organized and emacs starts instantly now
similarly, being able to configure emacs with a real programming language was a game changer compared to vim with vimscript. this is not so much an issue now with neovim, but i still prefer elisp :P
96 comments
[ 3.0 ms ] story [ 138 ms ] threadFor example, Eglot and use-package being part of Emacs core.
Additionally, there's also just many new plugins for the base-level things. I never thought there would be alternatives to completion frameworks like Helm or Ivy, until new ones came out. It's all been very exciting.
The one that I think makes most change is treemacs - this gives you a tree view at the side of the window of files.
> many new plugins for the base-level things
GP mentions Helm and Ivy. These "completion frameworks" are editor-wide, full-blown rich and ergonomic UI enhancements, each with its own philosophy. Each one is an island though - you have to buy into their philosophy wholesale[0]. At some point, however, the community identified the various paradigms and patterns in those completion UIs/frameworks, and where they map to existing core Emacs ideas, and a new breed of libraries were born - Corfu, Vertico, Embark, and many others, each of which provides a single piece of the equation, and deeply integrates into built-in Emacs APIs whenever possible. As a result, you can now mix and match those libraries to replicate something like Helm or Ivy, that works better, is more flexible, and more friendly to code against.
This is perhaps less interesting for casual users, but it means an important philosophical shift in community, towards more targeted and composable plugins. For casual users it just means more powerful, stable, better cooperating plugins.
--
Okay, I lied. Let me talk about Org Mode. My favourite little feature, which I miss from literally any other software I'm using (like Microsoft's To Do I've been using lately for ad-hoc personal things[1]), is `org-extend-today-until`. Made by and for people like me, who always find themselves reviewing plans after midnight, it's a variable you can set to make Org Mode extend "today" past midnight. See: http://doc.endlessparentheses.com/Var/org-extend-today-until.... I set mine to 3 (as in 03:00).
Flexibility of Emacs means people just implement random stuff like this in the first place - features not relevant to Minimal Viable User, but very useful for a subset of users.
--
[0] - Though in Emacs land, this just means it's only tad more annoying to extend, modify or repurpose pieces of those frameworks.
[1] - Org Mode is the bestest, but still has so-so mobile support; currently MS To Do is just the least annoying tool for private planning on the go.
That's pretty neat. Now I'm trying to remember how I live without it.
Pick any other tool. Plan something with it. Wait until it's late. Feel the frustration.
Serious question. What does org-mode give us which Google Docs doesn't?
* One ..
* Two ..
* Three ..
Now mark them as TODO items, with one being in-progress:
* TODO One ..
* TODO Two ..
* INPROGRESS Three ..
In Emacs you can then view your calendar, or org-agenda, which will have the current day and all items on it.
You can add a deadline to an item, and it will jump to that day on the calendar/agenda.
Can you keep track of simple items in google docs? Absolutely. Can you make them appear on a google calendar? No. (Yes I realize Google has todo-app, and that does. Even with recurring scheduling, but that's not tied in to google docs either)
Easy examples, any source that is delimited with `#begin_source language` will have whatever the editor would do for `language` in the delimited section. Searching the file is exactly like searching any other file. Committing it to source is trivial, as it is a somewhat normal text file.
And while org is not a perfect static site generator, it works surprisingly well for it. https://taeric.github.io/challenging-my-filesize-intuition.h... is a fun example I did not too long ago showing off some of the benefits.
That last actually shows how emacs can be treated like what a lot of folks use jupyter for. With the main difference that the "on disk" form is a somewhat normal text document using fairly trivial markup.
In this deeply nested Reddit comment, when someone said: "Imo emacs shines when editing, not writing.", I tried giving a few practical examples of how I use Emacs for writing plain text. I'm just gonna list the use cases without specifics, you can click the link below and find details of each package if you're interested. Note that this is a single aspect of things for which I use Emacs. Many other possibilities are abound.
Emacs is incredibly incomparable for writing. I don't even try to type anything longer than three words in anything else. I always try to find "edit-with-emacs" feature wherever I go - I built one for Mac, then I wrote one for exwm, then I did the same for stumpwm . I recently started using AwesomeWM, and now I have it there too. If I'm ever forced to work in Windows, I can promise you, finding a way to edit with Emacs would be the very first thing I will try to solve.
When I'm typing in Emacs, I have:
- Spellchecking. When I mistype the previous word, I would just tap the comma twice, and it autocorrects it. If I need to actually insert comma, I'd use comma and space (which I always do anyway)
- I have thesaurus.
- I have Google Translate, for which I don't even have to switch the keyboard layout, meaning if I want to translate from Russian, it would automatically switch the layout to 'ru' and back to English when it's done
- I can check the etymology and definition of any word.
- I can count the number of sentences, words and characters.
- I can keep an eye on my writing with writegood-mode, it can look for duplicate words and use of passive voce, and perform Flesch–Kincaid readability test.
- Until recently, I was using Grammarly to check the text, these days I simply send it to chat-gpt, and it even shows me the diff upon completion.
- I can toggle "distraction free, zen mode", for writing.
- I can launch a web search on any selected text.
- There are various ways how you can preview the markdown.
- You can write helpers like wrapping a region in a collapsible section, or create "code sections" without any hassle.
- You can edit the code sections in their language environment, with syntax highlighting and REPL.
https://www.reddit.com/r/emacs/comments/1aey0eo/they_are_sur...
Eglot is a package that works with LSP (Language Servers). There is another one called lsp-mode.
Eglot is integrated within Emacs over lsp-mode because it was specifically made to use existing hooks that Emacs has.
What this means is that you'd use the base Emacs command for finding a reference, and Eglot will populate the source for that command.
Whereas with lsp-mode, it has it's own command you'd run for finding reference. I do think you could also write code to have lsp-mode populate Emacs commands.
That being said, my impression is that Eglot has better integration with Emacs - which is why it became part of Emacs core.
(It's been a while since I've reviewed the Eglot vs lsp-mode discussions, so anyone feel free to correct me).
Use-package is a package for setting up your Emacs configurations. It allows you to place settings for individual packages in nice little sections. It's mainly used for organization but you also gain a plethora of options as well, like deferring to load a package until you open a file that requires it.
You also don't technically need to configure Emacs by hand by writing code lines. You could always do M-x customize and change settings that way. Emacs will auto-generate code from that and place it at the end of your configuration file.
That being said, this becomes quite messy to look at - so people prefer to use M-x customize to find the setting they want, and then they write it by hand in their config.
A big usage of use-package that I love is that you could specify specific settings that tell Emacs to enable it through M-x customize. If you don't know what I mean by that - that is totally ok. You'll learn about this more if you ever dive into Emacs and want to configure your own settings.
I guess you're supposed to have some version of Emacs already installed? Because the "Download" doesn't appear to include a binary, and the "Installation" just appears to set up your ~/.emacs.d/ folder.
Funny, I presumed that an "Emacs Distribution" would include Emacs.
I prefer Doom (https://github.com/doomemacs/doomemacs) to Spacemacs. However I haven't looked at Spacemacs for many years; perhaps it's now on par with Doom.
Que Emacs is an OS jokes.
[0] - https://www.braveclojure.com/basic-emacs/
It took about a week to finally get used to paredit-mode (and rainbow-parens, because…) but once I did it is the most productive I have ever felt, I keep trying to find that experience again.
Unfortunately the dynamic types and slow build system (lein) made the build step quite tedious (this was 11-12 years ago) - but in terms of expressing ideas, man - paredit + lisp style was amazing!
>You’re a curious person and a constant tinkerer who likes playing with (insanely cool) vintage software.
>You want to experience life outside the mainstream.
>You’ve always wanted to learn a bit of Lisp.
>You want to build an editor that’s uniquely tailored to your needs and preferences.
>You’ve got a lot of time to kill.
Is this sarcasm?
I think focusing on the killer apps might have hooked me more than that closer!
That said, it's pretty easy to put your Emacs config on the back-burner for a long time once you have things how you like them, and it becomes a much more OPTIONAL time sink at that point.
Using something like Doom Emacs could even prevent it from really ever being much of a time killer, but in my experience, once one is bit by the customization bug, one doesn't -mind- the time sink so much because the fruits of your labor are worth it
To illustrate this, I'm a heavy emacs user. I've been using emacs more or less exclusively since 1999 (I had two years where I forced myself to use vim to make sure I'd really given it a fair shake), including org-mode, using gnus for my email client, and writing code pretty much every day (with magit, helm, and projectile, tramp for working on remote servers). Here's:
20 commits in the last six years. A good chunk of them because I got a Mac last fall (for work) and so I finally had get my config working somewhere other than Linux. Mostly I only have to tough the config when I add a mode for a new language or when I go through a major OS upgrade that pulls in a new enough version of emacs that I need to make some fixes. I would say that none of those took more than 5-10 minutes of my time. I have about 100 commits total in my git history (so going back to about 2008). Meanwhile, I see colleagues using VSCode constantly trying out new plugins and configs. I think I've spent more time in pairing sessions in just the last year watching other people tweak their editor settings than I've spent configuring emacs in the last decade. When I get a new machine, I just clone that config repo and I'm good to go.MELPA isn't user friendly - I don't mean in the usability sense. The maintainers routinely remove packages that are being used. Breaking your end-user's dependencies for non-security related reasons seems unusual for a package repository. If it goes into MELPA and a user has downloaded it, it should stay there for basically forever or as long as feasible.
Performance - emacs is noticeably slow even on latest Apple hardware and I can't seem to get to it to an acceptable performance level. The bar for acceptable for me is VS Code.
Is it plain Emacs that's noticeably slow, or Emacs after installing 3rd-party packages? Some of the popular ones are very performance-costly.
That is completely wrong. I'm using Emacs back since when I was compiling it on 486 with 8 MB of RAM. nativecomp is the single biggest speed boost I saw Emacs ever getting. Using Emacs on the same machine with nativecomp on or not was night and day (a Core i7-6700 in my case: maybe the difference would be less noticeable nowadays but I couldn't tell as I now only ever run nativecomp and compile it with nativecomp on).
You're the first person I ever hear saying nativecomp doesn't make a difference.
I compile Emacs from source specifically to get nativecomp because of the obviously perceptible difference in performance. Maybe you have a much faster computer than the rest of us?
In the unlikely case where emacs -q is still slow, use Emacs Mac Port (https://github.com/railwaycat/homebrew-emacsmacport/releases...).
This is at least 2x perceivably faster than VS Code on Mac.
Hmm. I have quite the opposite complain. Why is when I install a single extension that enables Vim navigation in VSCode there's quite noticeable typing latency? And it's not a single plugin, I tried multiple. While my Emacs instance where I use over 300, built-in and third-party packages still feels quite snappy.
I'm not saying that Emacs built in such a way that it is impossible for a package to degrade its performance, that can happen, but if you know how to use the built-in profiler it's not that difficult to find the culprit and either remove it or try to find a workaround.
While typing this comment I googled, TIL - VSCode has very impressive Perf Tools suite for profiling. That makes it even more surprising, why would the authors of those Vim plugins, and I'm not talking about some obscure and esoteric thing, but supposedly popular, demanded feature, ship it with such obvious deficiency?
Observing this latency after adding just a single extension, frankly makes me question the long-term viability of using VSCode as my main code editor.
Learning vim definitely has its use.
But both vim and emacs have lost the code tooling wars long back. You can configure emacs and vim to to anything. And that is not a win vim/emacs users think it is. Nearly all the programmers out there don't want to spend time on sub projects, just to bring their tools to bare minimal working standards modern tooling provides out of the box. vscode just works, it works out of the box, for 99% of the use cases out there and it works phenomenally well.
Plus the whole idea of being able to write out code faster, or navigate faster made sense in UI paradigms of the old, where there were no windows, and a overall better UI experience. These days coding and navigation speed aren't even in the ballpark of factors that slow me down as a programmer.
And yeah, Org mode. Unfortunately Google docs do way more, and you don't have to remember dozens of commands to just make simple tables, add dates and bullet points.
In many ways Richard Stallman had an idea that emacs should have really had a WYSIWYG facilities. But Google Docs go even one step further as everything is saved on a cloud and you don't really have to worry about losing anything at all.
Emacs on the other hand is a great time pass hacking tool, if you are bored or just want to work on something cool.
Ah yes. Those very precious programmers, who can’t be expected to configure a non-proprietary tool, because they are too busy making another dopaminergic app at their corporate job. The medium is the message, I guess.
1. Solve the problem using a tool.
2. Solve problems that a tool has.
It should not be a surprise people pick 1.
The main point you're missing is that at some point in your career, inevitably, you'll collect so many tools in your toolbelt that you might become overwhelmed.
There are tools for debugging, searching, formatting, converting, documentation, device control, synchronization, networking, databasing, containerization, security, etc.
Most tools operate with data. And most of the time that data doesn't stay in the context of the same tool - you have to pass it somewhere else. The common approach of unexperienced devs is to become "a copy-n-paste programmer". No, not someone who grabs the code from StackOverflow. I don't know if SO has much value in 2024, I stopped using it a source of valuable knowledge long ago, I do occasionally find clues there, rarely complete answers, perhaps the complexity of my questions has changed, but I'm going off the rails here...
So, anyway, at some point you'd become more efficient in enabling tools to exchange data. Experienced Vimmers use terminal tools with piping, etc. Some of them develop really neat and powerful mini-automation workflows.
Emacs is another amalgamating medium that can be used for the same purpose. People with shallow understanding of Emacs often get grumpy for Emacsers wanting to do "everything in Emacs". Matter of fact, it's not about doing everything in Emacs, but rather doing everything _through_ Emacs. And that can be quite effective too.
So tell me, why is it so difficult for you to accept that Emacs is just another tool, not a replacement for some other specialized single-purpose tool, and that it is quite good at what it does - that is to work as a "glue" to orchestrate many other tools?
Maybe VSCode is truly better in that aspect than Emacs. I don't know. I have yet to find out. So far, people have been claiming that it just works better as a code editor in specific languages, but I haven't heard it being used as a "tactical unionizer" that can talk to many other tools in a way that Emacs does.
I honestly can't deny or approve this message because I haven't yet used VSCode extensively. But I have used many "phenomenally good" tools in the past. Borland stuff in the 90s was fantastic, MS Visual Studio in 2010s had some awesome features, IntelliJ IDEs today are amazing.
Over the years I've developed a distaste for proprietary products. Not because of money, it's rarely an issue. I happily paid for using IntelliJ products, even though I don't use them anymore, I still believe that they were worth every penny.
Perhaps it's debatable but the price for using Photoshop maybe is fair. Photoshop is a truly exceptional tool in its own category. I don't know any other tool that comes close, proprietary or open-source. Photoshop is the most creative graphics tool. But that's my opinion of an occasional, amateur graphics designer.
The reason for my distaste for proprietary tools for professional programmers is the lack of freedom to tweak, the right to repair, whatever you call it. I firmly believe that programmers should be able to program their tools.
Again, maybe VSCode already is as darn hackable as many people claim it to be. From my limited experience, I got the feeling that today it lacks some extensibility capabilities I'd like to see. But it's evolving fast, the pace of its development is quite impressive. Maybe in a few years, it could truly be crowned as the most hackable devs tool that outshines even Emacs. For me, Emacs is like Photoshop for programmers. It's the most hackable software product that you can tweak to perform any kind of crazy shit. But again, that is my opinion and a lot of people maybe would disagree.
Maybe Google Docs gives you the satisfaction and feeling that it lets you do more, not for me.
- Google Docs doesn't have vim navigation and I need that in my editor. Trying to convince me otherwise is like punishing a child for being born left-handed.
- Google Docs cannot handle my pdf annotations, I can't read a book while simultaneously taking notes. I mean I can, by having them in separate apps, but I won't be able to jump to the page from my notes and vice-versa. I can do that in Org-mode.
- In Google Docs I can't have code snippets that perform computations. I can't send a http request, then get the results and feed them to some Python, process that data through Clojure and spit out a diagram in .png. I can do this in a single org-mode document.
- I can't keep my Google Docs Zettelkasten-style, similar to Roamresearch, Obsidian or Loqseq. I can do that in Org-mode.
- I can still use Google Docs and link them from my Org-mode documents, I can't do the opposite.
- While typing in Emacs, I can automatically correct my previously mistyped word by tapping the comma twice. I don't think anything like this even remotely possible in Google Docs.
- I can fetch a definition, list of synonyms, etymology, translation of any word with a single, simple keystroke while I'm writing text in Emacs. I don't know how to do that in Google Docs.
- I can select a region of text and feed it to ChatGPT, asking it to fix mistakes, rephrase, simplify, etc. In place. No copying, switching, pasting. I simply select, press a few keys - voila. It even shows me the diff of what's changed.
- I can't encrypt my documents with my GPG key in Google Docs. I can't store my docs in a git repo. Even though Docs provide a great way of restoring and tracking history, I don't think it's grepable. Org-mode and Emacs manage my documents in git with git-auto-commit-mode, without my supervision.
- I can't easily export my Google Docs to Anki. My anki cards are stored within my notes - they are not separate entities that I have to manage in a different app.
- Google Docs can't manage my dotfiles. All my config files for zsh, bash, command-line tools, package-managers, etc., all kept in a single Org-mode document. Literate p...
I wouldn't go so far as to call native-comp feature a gimmick, but you probably won't see noticeable UI performance improvements with it. On the Mac, --with-metal support may give it a bit snappier feel but it depends on the hardware, you may try both, with and without and compare.
Matter of fact, Emacs with native-comp flag may give you an impression of things being super slow right after the startup, because it often has to recompile packages asynchronously, the process of which you can observe in *Async-native-compile-log* buffer, it's normal for Emacs built with native-comp to be a bit laggy for a minute or two at the startup, but you don't have to restart Emacs very often. native-comp benefits can be observed when using things like lsp-mode, where it brings some good perf improvements, sometimes it's worth it, but you also have to expect things to break, and quite often, native-comp relies on libgccjit, and MacOS updates often break the toolchain dependencies, and it can be highly annoying if you like to update Emacs packages often, especially when using something like Doom or Spacemacs, but it's not Emacs' fault. It's great that we have the option to disable native-comp completely without having drastically reduced performance, most of the time, you won't even notice it.
Also, one thing I always recommend doing on the Mac, which is absolutely unrelated to Emacs is this:
Reboot after setting that and trust me, you'd thank me later. Emacs would feel like it's on steroids. And remember, don't ever change repeat rate in Preferences dialog, it resets it to the values acceptable for muggles. Don't be one, be the keyboard wizard, let your machine fly.Async compilation does not slow down the startup time, it's not what I said. My Emacs instance also starts very fast, that is a signature feature of Doom. But do check your buffers, there will be *Async-native-compile-log* there.
What I'm saying is that when you start it, while it's running compilation asynchronously you may feel some slight, almost unnoticeable (or super noticeable - it's subjective) UI performance dip, it's not a big deal.
I get that it might be slow if you're trying to use it to automate something complex, as some part of a server, etc. but it more than keeps up with me.
WSL might make things faster.[1] IIUC, the problem is that starting new processes is much slower on Windows than on Linux/Unix and Magit relies heavily on that. This seems to have plagued Git tooling more generally but maybe this got fixed since then.[2]
[1] https://emacs.stackexchange.com/a/58444
[2] https://github.com/magit/magit/issues/2395#issuecomment-1710...
For example, Magit tries to display tags (in addition to branches) in the refs buffer, for the project that has too many, yeah, that may be slow. The solutions is simply to remove the hook
It's just a single, isolated example. People complaining "Emacs is slow", is like choosing to drive a nail with the handle of a screwdriver and complaining how hard that is. Well, maybe learn how to use the tool, no?Emacs is a Lisp machine made to run Elisp byte-code. It's not a final product built with some C and Elisp that you may never need to learn. You do need to have at least some basic understanding of Elisp.
Even if someone is impatient, they could develop inner curiosity and type in ChatGPT "what happens when Emacs opens a buffer". Basic understanding of standard hooks and hooks in general, advising functions, etc. is all required for you to be the "user of Emacs". No wonder we see people claiming to have used Emacs for over a decade and still switching to VSCode. Turns out, most of them never wrote a single Elisp package, or ever understood how some copy-pasted magical elisp snippet ever worked. I can't claim to be a chef or even good at cooking if all I ever do is microwave pizza. Even if I did that for twenty years.
I'm not saying that everyone using Emacs should know how to setup Gnus, master keyboard macros or should be able to whip up a new minor mode in zero-gravity. But please try the built-in Profiler. Learn how to use describe-command, describe-key, etc. It is not that difficult.
So it’s, like, not an accident that emacs can leverage this :-D. Though I never see anyone giving him credit.
Thanks steve for all the things.
That is cool. I was thinking just today (without knowing it was the intention) that LSP has meant I moved from an IDE to an editor with plugins (Kate, not Emacs), because an editor now has so much more of what the IDE can do.
He was ahead of his time on dev tooling. I'm still using js2-mode to this day.
semantic-mode almost, a-a-a-lmost did something similar (mostly based on LR incremental parsing) but was Emacs-only and never gained enough traction.
Tree-sitter is decades ahead of both. It's hard to compare js2 to a modern GLR incremental parser generator of Tree-sitter. I am not even talking about the size of the community building grammars useful in all the editors out there.
- A guided tour of Emacs: https://www.youtube.com/watch?v=lkIicfzPBys
- Emergency Emacs: https://www.youtube.com/watch?v=6ZWp05OW1c0
Which is not to say that Yegge and others haven't created some nice things. They have. I tend to see it more that they succeeded at problems previous people had either failed at, or had a much more limited success. Progress is not always new things. Nor is similar effort always informed by each other.
The most important medium through which we convey ideas, information, and even emotions is text. Often, programmers place a greater emphasis on the formal language of precise and structured nature of programming languages. They may even become emotionally attached to a single programming language. Notoriously, most people overlook the importance of plain, simple, unstructured text. The value of taming the wild nature of plain text (even before programming languages) is underestimated.
Find Graydon Hoare's post "Always bet on text", it's revelatory.
One can spend many cycles learning tool after tool, jumping from one to another, newest, shiniest, "most innovative" thing that comes out, in attempt to find the most effective way, most productive way, most delightful way to gain power over text.I myself spent years trying things like Evernote, OneNote, Google Keep, Notion, Workflowy, Apple Notes, Zoho Notebook, and countless other tools.
There were always some factors that made me switch. Initially I decided to learn Emacs, thinking it's just another code editor. It took me quite some time to master it to the point that I can now bravely try to implement some wildest ideas. I came for a specific tool for coding, instead, I found a world of incredible possibilities to manage text, any text, not just programming. All my notes, all my writing, my browser history, retrieving YouTube transcriptions, Anki cards, pdf annotations, emails, rss feeds, and of course, coding, all that I do in Emacs.
Why? Because it is not only extremely powerful and allows me to be immensely efficient. It also gives me enormous pleasure, allowing me to perform things my way. If frustration could be measured in wasted fiscal expenditure, Emacs would've saved me quite significant amount of money.
Yes, that long-term satisfaction and liberating power were not granted to me. I had to spend many hours, days, and months of learning until I felt empowered. But that is a lifetime investment that is unlikely to ever diminish. Even if Emacs itself becomes obsolete, the mindset it helped me develop will remain. I will never be the same again. No other highly specialized tool will sway me to pay for it or waste my time, unless it is as extendable as Emacs. And there's nothing today that comes even close. Anyone who says otherwise either doesn't know the limitations of their tools or is unaware of the capabilities of Emacs.
Now? There is one left (yes, I switched to VS Code :() who still uses Emacs and there are even more Vim users (not admins!). And whenever I read something about Emacs online it's mostly Magit (I don't get that, I either use the CLI or a real GUI frontend) or Org-Mode (not for me either).
For C++ maybe.
For C most used Vim
(FWIW I like Vim; this isn’t an example of an Emacs fan touting their advanced ide-like editor).
And hey, no editor does Emacs key bindings emulation as well as Emacs itself.
Joke aside, the key bindings work in a lot of places outside of emacs, which unfortunately are slowly eroding away.
Keybindings are all a crapshoot when it comes to working with different platforms though. macos is notably frustrating in this regard.
Try the experimental compose interface https://xenodium.com/a-chatgpt-shell-compose-ux-experiment
I found myself using it the majority of the time.
I need to review the current state, but back about half a year ago, when I evaluated them all, I had a lot of "fun" getting them to talk to Azure OpenAI (instead of OpenAI). Or even to allow to override the system prompt. Granted, those were early GPT-4-by-invite-only days, but still.
Still, the most important takeaways are that:
- Emacs community can and does react quickly to any new development;
- Sure, early on the packages may be somewhat half-baked, but it's not that hard to improve/fill in/fix them on your own, with config tweaks and maybe a pinch of simple Emacs Lisp code, even if you barely know anything about programming. That's in contrast to just about any other editor or program, where this is just not possible.
https://www.youtube.com/watch?v=bsRnh_brggM
OK that's an exaggeration, I have dabbled with org-mode and use magit, but really for editing code, it's pretty much same as it ever was for me.
Evil-mode is not the only way. There are other approaches like devil you might want to check out.
I personally suspect that the big reason behind Emacs' resurgence is the feeling lately that computing is no longer responsive to user needs. That it's all about designing, and redesigning, and redesigning again, interfaces to make pretty screenshots, with the user being totally downstream and hardly even a factor in the minds of whatever designer has been assigned to work on the product most recently.
Emacs by contrast gives you an ugly interface that cares about function almost to a fault, that you can then make your own. It gives you the tools to look inside what the program is doing and change its appearance, its functionality, how much or how little information it shows, what that information is, etc.etc. All without constantly shifting under your feet, even with the significantly accelerated development over the last few years.
I do have some concerns about that last part to be honest, with Emacs seeming a little too eager these days to add features that seem to violate its underlying philosophy or design, but it doesn't seem like big, breaking changes are happening on the regular, so for now it's still a platform you can develop atop of as an individual, and feel like you understand and can at least partially map out in your mind.
In short, it presents a philosophy and experience of computing that you don't get very often anymore, even in open-source, especially if you're not a fairly advanced programmer already.
use-package, hands down. my decades old rat's nest of a config actually became organized and emacs starts instantly now
similarly, being able to configure emacs with a real programming language was a game changer compared to vim with vimscript. this is not so much an issue now with neovim, but i still prefer elisp :P