Comment by iLemming
2 months ago
Younger folk and beginners keep ignoring Emacs (and Lisp in general), without the slightest attempt to even understand what kind of philosophy makes it appealing.
The profound difference lies in ontological fungibility – Emacs isn’t software you use, but cognitive clay that becomes an extension of your mind’s operating system. Where any specialized app is inevitably doomed to constrain you to some kind of constructed imagination of what note-taking/knowledge work should be, Emacs+Org erases the distinction between a tool and thought through radical philosophical pillars.
1. The Medium is the Message Paradox
Emacs rejects the app paradigm's fundamental axiom. Instead of being a "notes app" or "writing app", it's a meta-medium where:
- Your notes can spontaneously become a calendar event → spreadsheet formula → email draft → code compiler
- The act of writing is programming your environment (Org markup becomes executable functions)
- Tools aren't discrete entities but fluid expressions of your current mental state (e.g., I can run a shell command piping it to grep and then pipe the results into a text buffer)
1. Agency Through Textual Primordial Soup
By rooting everything in plain text + programmable buffers, you're working with the substrate of computation itself. Unlike database-driven apps that entomb your ideas in rigid schemas:
- Every thought remains perpetually protean – a TODO item can morph into a API documentation generator through markup alone
- You manipulate knowledge at the level of semantics (headings, tags, properties) rather than fighting GUI metaphors
- The friction between "taking notes" and "building systems" disappears – your journal entries are the configuration files of your life (I manage all my dotfiles — for Linux, Mac, home and work machines via Org-mode)
1. Compounding Selfhood
Specialized apps optimize for atomic efficiency; Emacs thrives on continuous identity investment. Each macro you write, each Org capture template, each minor mode becomes:
- A cognitive microhabitat that evolves with your thinking patterns
- Permanent infrastructure that pays compound interest (my 2010 Org config still works, while Evernote of 2010 is abandonware)
- A mirror of your epistemology – the keybindings/hierarchies are your neural pathways externalized
This creates an irreducible satisfaction: you're not just using tools but cultivating a personal universe where every interaction leaves permanent fertile ground for future growth. The specialized app user lives in rented apartments; the Emacs devotee walks through an ever-expanding mansion whose rooms rearrange themselves to their thoughts.
People definitely sleep on emacs, which is a shame, but I do get it. I switched to emacs fulltime for coding for my work a few years ago, and really had it tailored to my preferences but drift (that took just slightly too long for me to keep up with while on the job) combined with AI features in other editors led me to land on Zed for code, which saddened me but is probably the best fit for coding.
However, Org-Mode is seriously a killer feature that is well worth it on its own. I use emacs to handle all my finances, notes with org-roam, blogging with ox-hugo, dotfiles in a massive org-tangle document, etc. I couldn't find anything remotely to compare it to, and have failed attempts at switching. There are tons of ways of interacting with Emacs that are just lightyears ahead of anything else. Literate programming and tangle are a godsend for tons of different use cases for me as well. I even keep running notes in the base of my codebase so I can hop to various files and capture locations in the relevant files as links in notes.
The only pain point for these tools for me is trying to use them as part of a commandline integration. I really wish org-mode and org-roam's functions were callable outside of emacs, e.g. for automated document generation from org-mode. One of the most painful things I've had to setup is an org-roam-server integration that updates and deploys org-roam-server when the git repo containing its files is updated. Only way to do that seemingly is to run emacs in a very strange way inside of a docker image. Intuitively it feels like org-roam-server should be able to build itself into a static website for deployment. Might seem like a nitpick, but it's really not -- that interface is a huge part of why I use it and not being able to host it without horribly hacky workarounds seems like a massive weakness.
Which is why I've settled on neovim; I've written my code to be as modular as possible, so I can pull it in an CLI program if needs be.
Neovim is a text editor. You can't compare Emacs with just a text editor. Just like you can't compare Emacs with a browser, music player, note-taking app, email client, etc. Emacs, first and foremost, is a Lisp REPL, with an embedded text editor. Without deeply understanding and respecting this aspect it is difficult to appreciate what Emacs could be, what you can do with it.
Imagine this — one morning I was watching my colleague showing me a bunch of things over a Zoom video, and I didn't feel comfortable interrupting him with "wait, don't scroll away, I didn't get that, allow me to read it", "hold on, I'm taking notes", etc. I sacrificed my lunch break to write a small Elisp command that runs tesseract to OCR the image in the clipboard. Now, I don't even have to ask my colleagues for explanations or tell them to share the url they are currently browsing — I can just grab it with a couple of keystrokes to make a note. And that's just one, single, isolated example. It cost me twenty minutes of my time. Twenty minutes of investment that paid itself many times over already. And I have tons of similar examples.
4 replies →
> I really wish org-mode and org-roam's functions were callable outside of emacs
What are you even talking about? It's like wishing for java programs to be able to execute without JVM, or Erlang-code without BEAM. While that's theoretically possible to a certain degree (using Graal and Lumen), it's not easily achievable.
Org-mode is written in Elisp, of course it needs Emacs to run. You just need Emacs executable and you can absolutely run scripts in batch mode. I have done it many times, running tests on GitHub Actions, etc.
I thought I was pretty clear? It would be nice to be able to call functions from org-mode and its related packages without having Emacs installed, or with some minimal subset of emacs meant for the commandline which caters to the needs of people running headless commands. It would solve a whole ton of issues for me. In particular, org-roam-ui is amazing. To run it, I have to open emacs and then... have emacs launch it into a browser for me. But the hosted interface won't export to anything that can be statically (or dynamically, really) hosted, so I can never access this awesome note-viewing interface from the web, even though to do it locally I already have to use a browser?
I have a project for hosting org-roam-ui as a website that took a ton of finagling to figure out and is extremely brittle. I had to finally load a custom .el script to prepare emacs to even try to evaluate the 'org-roam-ui' command from the commandline. If emacs prioritized headless / cli operations, this wouldn't have been such a nightmare, but it absolutely was. Just finding the right ports and re-assigning them to get out of each others way was a huge learning curve even for a seasoned emacs-er.
> It's like wishing for java programs to be able to execute without JVM, or Erlang-code without BEAM
No, it's not. It's wishing for basic functionality offered by all other markup languages of which I'm aware. That includes latex and everything supported by pandoc. Org-mode can do all sorts of crazy rendering tasks from its files, and it is worse than pulling teeth to get that functionality into a build pipeline of any kind.
"What are you even talking about?"
Not understanding something is not a virtue, not something to act smug and superior about.
"It's like wishing for java programs to be able to execute without JVM, or Erlang-code without BEAM."
No, it's not like that.
"Org-mode is written in Elisp, of course it needs Emacs to run."
There are (incomplete of course) apps outside of emacs and elisp that process org-mode files. And even if there weren't, it makes sense to wish that there were. In the mind of a clear and competent thinker, the mere fact that org-mode needs emacs to run is not a reason not to wish it weren't.
1 reply →
(Long time Emacs user, abandoned since VSCode became a thing because it hurt my wrists so much.)
Do you think what you're talking about is hard to demo?
"- The act of writing is programming your environment (Org markup becomes executable functions)
- Tools aren't discrete entities but fluid expressions of your current mental state (e.g., I can run a shell command piping it to grep and then pipe the results into a text buffer)"
I haven't seen an impressive demo of this kind of stuff tbh.
No, it's not hard to demo, and I've been thinking about making some vids, but it's just difficult for me for multiple reasons. Besides, the whole topic feels too grandiose to cover easily and make it satisfying for every level of expertise — newbies and seasoned veterans.
I'm a regular dweller of https://www.meetup.com/emacsatx. We meet every first Wednesday of the month - if timezone permits it, come talk to us if you have specific questions. I will promise you though to make an effort to produce some demos and publish them.
Very impressed by Rainer König's Org-Mode tutorial series on YouTube. He manages to keep most episodes under 15min. As you progress the knowledge keeps building slowly. Highly effective. His paid courses are likely even better. During the 1st series He only touched init.el a few times. Opting instead for using Customize functionality. He used the default theme, if you can all it that. Toolbar on and menu bar and he used them during the sessions.
System Crafters tends to mostly do live streams for more a couple of hours. You learn a lot watching them. But many people don't have the patience for that.
1 reply →
> wrists
there is evil-mode, even mouse support ;-)
Did you use evil mode? I am basically just running Spacemacs and I don't often need to use ctrl and option most of the time by leveraging the modal editing.
Love this ! But I disagree to the thought that youngsters don't use emacs. It is amazing to actually see a number of people who are very young learning about emacs and loving it. The community behind emacs was always niche but it is amazing that in every generation there are people who resonate with its ethos and mental models.
Young people and beginners don't even know these things exist, and if they do happen to know they exist they have no reason to look into them. It's absurd to attack people for not "attempting to understand" something that they don't know enough about to have reason to "attempt" it. There are all sorts of technologies that I haven't "attempted to understand" (including many emacs packages) because they aren't on my radar or I haven't been made aware of their value. This lack of an attempt is not some sort of flaw.
I'm not trying to attack or blame anyone, but rather share my empirical observations. "Young people and beginners don't even know these things exist" is also along the same lines of thought.
> This lack of an attempt is not some sort of flaw."
It could be, but perhaps on the other end here — maybe the evangelism and elucidation are at fault? Seasoned adepts often forget "the beginner's journey" and can't break through the "communication disconnect". It's hard to explain the "what" and "how" without effectively conveying the "why", especially when the other side is not interested in hearing the "why".
I'm just sad that a lot of very talented folk either choose to ignore or deliberately dismiss some great ideas, building their assumptions based on some shorts they watch on YouTube or TikTok.
The lack of attempt may not be a flaw, but maybe "the lack of attention" is our generational flaw? Maybe while I'm focused on Emacs and Lisp, I'm failing to see a bigger picture, where tons of other pragmatic ideas get dumped overboard because they don't align with the prevailing narrative?
I think it is way simpler than that. IMHO, for many people young or old the value proposition of emacs simple is no longer there and/or worth the huge learning curve. For most things people would use something like emacs the alternatives are simple good enough and some cases better. By better I mean mostly more accessible, less complex and with a better ecosystem. One tool that does all, also simply does not resonate with everyone nor do many people feel the need to make their almost their lifestyle (not saying you do, I'm speaking in general to the Emacs runs my life folks). Another thing to consider often is that when working in a group or team at work for example it can be the easiest path forward to use the tool the company officially uses and your teammates do. If your team uses for example slack to communicate why go through the hassle of setting up some most likely cumbersome workaround to target it via emacs instead of just using the slack.
2 replies →
All excellent and true points. However, it is my personal opinion that first impressions matter. When a newbie installs Gnu Emacs the default theme and overall appearance of the GUI is shockingly dated and the defaults are bizarre compared to 'modern' UX. That's what happens when you create software 40 years before there were any UX standards. Heck there was no mouse and no arrow keys on most keyboards at the time. Full screen editing was brand spanking new. The vi editor came after Emacs because UNIX came after Emacs.
Most new young potential Emacs users are students and new developers being raised on VS Code or JetBrains IDEs. Which out of the box appear modern to their young eyes. So when they see vanilla Gnu Emacs the reaction may be, "Okay Boomer, whateva".
I would argue that the reason Spacemacs and Doom resulted in such massive growth of the Emacs user base had less to do with evil-mode and more to do with attractive theming and applying reasonable default settings that match how those modern UX IDE's work. Not to mention the myriad of YouTube videos about them.
I fail to comprehend why the old school graybeards refuse to update the default appearance of Emacs. Of course the out of box experience should be mostly spartan but it could look a whole lot prettier. I would like to see Emacs devs adopt Prot's standard light and dark themes, they need to replace the traditional default theme and be distributed with Emacs. The default theme can hardly be called a theme, it likely predates theming in Emacs.
I don't know anyone who sticks with the out of box appearance of Emacs.
I think we are going to need some curated video demonstrations including slow-motion and key presses being shown. Real world tasks being demonstrated. Including eshell and REPL, etc.
I too have been toying with creating some of these demos. We need to create focused compelling videos that are rather short. Showing off just how great Emacs is overall. Seeing is believing.
So many junior devs never saw Emacs and only maybe they heard something about it but never took a deeper look. It is always some rogue graybeard who shows off in front of junior dev and that dev needs to pick their jaw off the floor. similar occurs with Neovim.
We also should be targeting non-developers such as writers and researchers and students. I know some people who use Emacs to manage their Dungeons & Dragons games. Both as a dungeon master and as a player. Heck I use org to take notes while I am playing a complex video game.
We should espouse the wonders of Plain Text and how you'll never be locked into a proprietary file format. You can use it with Git for revision history and tracking changes. The power of Elisp enables non-developers.
We need to start a sort of grassroots marketing campaign to spread the word. In a nice way. i.e. don't bash the competition. Just show what Emacs can do in short highly focused videos. Emacs can speak for itself.
> my personal opinion that first impressions matter.
It certainly often does, but there also examples where maybe it's not the biggest issue? git, vim, LaTeX, ffmpeg — they all find their users despite being so demonstrably bad with "the first impression".
Besides, I feel here you're talking about Emacs-the-text-editor, while what I'm rather babbling about Emacs-the-lisp-machine. You see, my point is, people talk about Emacs-the-text-editor all the time and keep arguing if it's "modern enough" or "outdated", "archaic" or "useless". The same way it can be rationalized as Emacs-the-web-browser, Emacs-the-email-client, Emacs-the-IDE, Emacs-the-version-control-system, etc. Of course, anyone who learned how to operate a decent email client perhaps wouldn't ever see a point of suddenly switching to Emacs-the-email-client, unless they could look at it from my POV — a Lisper's point of view. Because the email client aspect of it has been thoroughly imbued with Lisp, it makes it extremely appealing terrain for me — I can with relative ease erect my creations on top of it, limited maybe only by the boundaries of my imagination, rather than technical limitations.
If only it was possible to convince an entire generation of programmers of unthinkable elegancy and pragmatism of Lisp, wouldn't that be great? Imagine a world where "every programmer knows some Lisp" is the norm, rather than the current assumption that "every programmer is familiar with Javascript, SQL, and Bash" – which, in reality, is almost universally not the case.
That is the essence of my plea — it isn't so much about Emacs itself, but about the widespread ignorance of coders who dismiss Lisp as an idea. If that weren't the case, we wouldn't even be here, discussing the reasons why Emacs is so unpopular.