Watching the Emacs community, I’m always just blown away by the love and adoration it gets. It’s clear to me that there’s something magical in it, but I can’t seem to tap that magic for myself. I’ve tried - really tried, including relearning lisp - to adopt Emacs roughly four times over my career; it never stuck. I understand the basic benefits, eg keyboard-optimized workflows, deep customization/malleability, etc. But despite my attempts, it just isn’t… accessible to me. What the heck am I missing? Should I just recognize that it’s just not for me?
You say "it just isn't accessible to [you]". If I'd install vanilla Emacs today or one of those distros, I'd probably feel the same, i.e. that Emacs is not for me. However, what makes Emacs great is that I can make myself at home in Emacs and design everything the way that works best for me personally, even if that is perhaps highly idiosyncratic. So my advice would be: Install Emacs and if there is something that you don't like, don't ask what you're missing, but simply change it. One thing I hated about Emacs were the RSI-inducing keybindings. And this is how I became one of the first 5 users of evil-mode (which provides vim keybindings). Over the last 15 years my Emacs config has grown to 4k+ lines and that seems bizarre, but the result is an editor that works really well with my personal way of thinking. It almost feels like an extension of my body, which means that I use it without thinking about it. It gets out of my way cognitively and doesn't add extra friction to my work which is already complicated enough. That's worth a lot to me.
So for you, Emacs is more like a library or editor engine than an application? That makes sense and may explain why I didn’t connect with it, in that I’m used to adapting to my tools rather than building them. I need to change contexts frequently so I’ve made myself malleable rather than my tools.
That's a great explanation, you have quite the way with words!
I'd add that it isn't only about preferences. Obviously if it works equally well either way, you save time and energy by just adapting yourself to your tools and appliances and moving on with your life. But doing so sort of sets a ceiling on what you'll ever imagine any tool can do... This touches on what I'm getting at: https://djrobstep.com/posts/programs-are-a-prison
Maybe you just haven’t found a killer feature for you yet that blew you away. Personally, I also can’t give you THE one use case that sold me on Emacs. It’s more the integration of a diverse set of tools together with its robustness that really makes it shine.
I have used vanilla Emacs for a long time with only a couple of packages installed (basically flyspell and web-mode) and everything worked for me although it was quite boring. That’s because I managed most of my dev workflow outside of Emacs. The JS dev server took care of reloading and transpiling, the linter ran as a test step and I used git on the command line for version management.
These days I do a lot of backend work, most importantly REST APIs. So have to tweak server code, restart the server (not always written in JS), test out new end points. So I am using the built-in „compile mode“ running a bash script automatically deploying my code changes using ssh upon two key strokes (C-c C-r). Emacs returns syntax errors including file names and lines, so I can jump straight into the code to fix the issue. Once running I switch over to a „restclient.el“ session to try my code. With another two key strokes (C-c C-c) I execute a request (however complicated) and receive the JSON response in a temporary side buffer which I can filter using „jq“ with another key stroke thanks to restclient-jq.el. I can inspect runtime errors on the server by opening the remote log file using TRAMP mode (alternatively, I open a „term“ session and invoke „tail -f“). Once the code works I press „C-x g“ to switch over to „magit“ to stage or commit my changes. If I have to work on two or three things in parallel I use „perspective.el“ to maintain something akin to virtual desktops, so I don’t have to re-order my buffers all the time. I also do teaching on REST APIs which I do using „org-mode“ together with „org-babel“ and „org-tree-slide“ allowing to inline actual restclient.el sessions among text or graphical slides. I also use org-mode for technical documentation including executable code and for explorational SQL development. You see, in Emacs many packages just glue together seamlessly thanks to its brilliant API that stood the test of times.
I didn’t start using all of this on a single day but Emacs sucked me into its eco system very slowly until I just couldn’t imagine using anything else anymore. It just takes time to get to know these things and getting comfortable with Emacs‘ configuration system.
Emacs is a lifestyle and it takes time to get into it. The jokes are pretty spot on - it's a wonderful operating system; it only needs a decent text editor.
You'd probably have to "dedicate" yourself to it for a month or more (and having a "mentor" or support group that can answer questions and telling you there's an easier way to do it would help).
It was MUCH more powerful (relative) when we didn't have much beyond a terminal emulator.
I don't know. I used emacs for a solid year (in evil mode admittedly), and my configuration kept breaking with new updates. I spent more time fiddling with my config files than being productive. I love lisp and the idea of emacs. But when I started using vscode, my productivity immediately jumped. Emacs also suffers from latency spikes, even worse than vscode does. I want Emacs, but with the speed of Rust, and the polish of vscode.
I don't think that's what he is saying. He is saying that Emacs once ruled supreme because it was the only option. Now that IDE's have caught up, it's in the lead by only a little.
I'd say still by a lot, but yeah, IDEs have advanced in the last 20+ years (and one of the main advantages of something like VScode or IntelliJ is that it does a lot "out of the box" and it's pretty discoverable).
What I tell my programming friends is that if you can see yourself molding your computer user-interface as sort of a hobby, then emacs is most definately for you.
If you don't see that as a fun past-time activity, then I would not recommend emacs.
For instance, (in my emacs email client) I just made a change where if I want to search the subject I am looking at, and it has a #XXX in it, then the subject search is just that number. Makes me able to quickly load up all emails related to that ticket. This makes me happy.
> Makes me able to quickly load up all emails related to that ticket. This makes me happy.
Yes, I love this.
Relatedly emacs is good if you find small annoyances or imperfections hard to "just deal with" and have the time and skill to customize or "craft" your emacs.
As a guy that has used both spacemacs and doom emacs (which I would recommend over spacemacs), I disagree - you still will be mucking around with things. Emacs out-of-the-box 2022 leaves a lot to be desired, configurations makes it easier, but it is still not the vscode experience, even though it helps you a LOT on the way.
I do think that keyboard optimized workflows are not for everyone; you should use what works best for you!
However, Emacs distributions like Doom Emacs or Spacemacs are definitely more approachable and featured OOTB than vanilla Emacs.
For me, the benefit of Emacs is that it's a single environment I can do everything in. I also am the type to enjoy messing with my workflow.
IMO most of that can be replicated with VS Code in a much more user friendly manner (VS Code remote editing blows TRAMP out of the water), with the caveat that multiple projects means multiple windows, it's difficult to have an entirely mouseless workflow, and in general it's less customizable than Emacs.
I personally never bothered to learn Emacs keybindings and instead use Vim keybindings in every editor I touch; VS Code and Emacs both have excellent Vim plugins.
Honorable mention: Neovim. It is lighter weight than either Emacs or VS Code but can still have pretty much all the bells and whistles. Definitely cool if you prefer to live in a terminal.
> VS Code remote editing blows TRAMP out of the water
One place emacs has a huge advantage is it doesn't use hardly any resources in the docker container.
The vscode remote server instance uses a constant 15%-30% however.
In real world terms this means a compile that takes 1 minute for me takes 2 minutes for my coworkers that use vs code.
There are many potential confounding factors that could affect the performance discrepancy of course, but I think it's still useful given I can't think of many other plaform differences and that it's consistent amongst my coworkers.
> VS Code remote editing blows TRAMP out of the water
I think it is not that black & white. Recently I've used tramp to dial into a server via SSH and there into a docker container and directly edit files inside. I don't think VSCode can do the same inside a shell it starts. Sure it may be able to open an SSH shell and then from there you might be able to type in some docker exec command. But that is not the same as tramp into docker container on a remote host via SSH for the following reasons:
When I use keyboard shortcuts from inside that tramp shell, Emacs understands, that it happens inside the tramp context and for example will only show me files inside that docker container, when I do a find-file. Should I decide to run an rgrep from that context, it will show me results in that context. If I click the findings of that rgrep, it will probably open the findings, which are on the remote host inside the docker container. If I open dired from the tramp context, I will see files from that context, not files on my own machine. Context is the magic here.
This level of integration is missing from VSCode. VSCode replicates part of these things, but things are not integrated. Want to ssh into a server? OK can do. Want to open files? OK here are your files from your own machine. It does not understand, that it should use the generic action of showing available files in the context of the opened SSH session. This might be a consequence of things being less coupled with keyboard workflow. When I use a mouse to click some menu items, it is not clear to VSCode in which opened tab/buffer that action should be performed. When I press a keyboard shortcut in Emacs, there will be a buffer (or mini buffer, or whatever) which has the focus and does not have to lose the focus, because I am not using the mouse to click outside of it. Things which are taken for granted in Emacs (all that integration and generic actions, which work anywhere) do not seem to exist in VSCode. Maybe most people are not even aware of how generic actions like opening a file could be integrated, because they have never seen it like it is in Emacs.
On the other hand, VSCode might have a more fluent experience for when you do not want to do anything more complex than SSH into a server and might be speedier at those simpler workflows. There are probably well paid engineers at MS, who try to make things run smoothly when the shell is an SSH session on a remote server. I have not benchmarked this. Just a guess.
> Want to open files? OK here are your files from your own machine. It does not understand, that it should use the generic action of showing available files in the context of the opened SSH session.
Are you sure? If I launch a remote session window and click open file/folder, it's on the remote (either SSH or docker for my workflows).
VS Code runs a server on the remote with any plugins (including LSP servers) installed with it. This is as opposed to Emacs, which AFAIK does not have a server on the remote and instead interacts with the remote directly using SSH (or `docker exec`, etc). Note, you still need to have any LSP servers installed on the remote if you want that capability.
I would argue that VS Code's remote editing experience feels more integrated than Emacs with TRAMP; I've had issues before where something is more difficult to do over TRAMP than locally, but I've never had that with VS Code.
You're right though, "blows out of the water" is a stretch, I just have fights with TRAMP fresh in my head haha
In terms of making editing on a remote seem just like editing locally, both VS Code and TRAMP are capable, I just find VS Code remote editing to be much more user friendly. It just works with little to no configuration.
> Are you sure? If I launch a remote session window and click open file/folder, it's on the remote (either SSH or docker for my workflows).
I am not sure about dedicated extra windows. I've not seen it being done in an ad-hoc started shell, inside a normal VSCode editor instance, at least. If it is a new windows (new process) it is not really the same, as the new instance is then dedicated to being a remote session one. With Emacs one does not have to start multiple instances to get things done, but does everything out of the same instance.
Whenever I see people closing and opening VSCode instances, I feel like: "Why did you close that?! Can't you just do things in your editor without frequently closing and opening it again?" It feels like an inefficient process. "I can't do it in this instance, I need to close it and open a new one from another working directory.". I can only speak from what I have observed people doing when screensharing. Maybe other people do it differently or more efficiently.
> VS Code runs a server on the remote with any plugins (including LSP servers) installed with it. This is as opposed to Emacs, which AFAIK does not have a server on the remote and instead interacts with the remote directly using SSH (or `docker exec`, etc). Note, you still need to have any LSP servers installed on the remote if you want that capability.
Emacs has had a server program since ages. You can run Emacs as a server, for example on a remote host, or on your local machine and when you start a GUI or non-GUI Emacs, start in client mode, to connect to the Emacs server. Your Emacs client will benefit from whatever you have set up the Emacs server to do. If your Emacs server has LSP stuff set up, you will be able to use it in your Emacs client.
For merely accessing a remote via SSH and accessing files in it, editing them and saving them, Emacs truly does not need any server. It channels anything one does through the SSH connection and "commits" to the remote's filesystem.
I agree though, sometimes tramp can be a hassle. It could be better and better documented as well.
> Emacs has had a server program since ages. You can run Emacs as a server, for example on a remote host, or on your local machine and when you start a GUI or non-GUI Emacs, start in client mode, to connect to the Emacs server.
I know about that, but AFAIK running Emacs server and client on different machines isn't really supported? Like all Emacs client is doing is executing some Elisp on the Emacs server to tell it to spawn a new frame the same way you can from a regular Emacs instance (that is, the frame spawns on the remote, not locally).
Regardless IMO just using TRAMP and just installing an LSP server on the remote is the simpler and lighter weight solution. The big thing is, I don't want to have to set anything up on the remote. An LSP server that can be easily installed by the system package manager with no further configuration is okay, I deal with that. Anything more, nah.
> With Emacs one does not have to start multiple instances to get things done, but does everything out of the same instance.
Yes, this is a tradeoff, and me being more comfortable with that workflow is one of the reasons I use Emacs. In fact, if so desired, you can still launch multiple instances for different things; me being able to fine tune my workflows instead of my tools dictating them is the big draw of Emacs for me.
>>Whenever I see people closing and opening VSCode instances, I feel like: "Why did you close that?! Can't you just do things in your editor without frequently closing and opening it again?" It feels like an inefficient process.
This is one more thing which emacs/vi people don't get. Most people don't care for things like start up time, or restarting their editor/ide a few times. Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff. When you optimise for things like these, at the expense of features like full remote integration you are optimising for things that majority don't care for things that are irrelevant in the context of modern day development.
>>You can run Emacs as a server, for example on a remote host
vscode is all about doing work the user should be doing. Nobody should be spending lots of times, in case of emacs that's often weeks to months of effort configuring and tweaking things that should come and work right out of the box.
> This is one more thing which emacs/vi people don't get. Most people don't care for things like start up time, or restarting their editor/ide a few times. Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff. t care for things that are irrelevant in the context of modern day development.
It is not, that they/we do not get it in general. You are painting with a very broad brush there. Not all Emacs or VI users are the same. Not all of them/us are endlessly optimizing startup time. Often the opposite is true. We do not optimize it, because we start Emacs when the day begins and close it, when the day ends. Because why would we ever close it at other times? No need to.
It is probably more, that many see it as inappropriate functionality, when one has to close the application and re-open it to do something so simple, that comes out of the box with Emacs. We are used to have this functionality without restarting and we wonder how one could accept this kind of shennanigans.
With VIM or its variants I can tolerate it a bit more, as it is more minimalistic than Emacs in its approach. It is often used as a quick command to open a file on a server, safely (model editing) edit the file and exit (no jokes now!). A one-off operation, not a long session of developing. There are people doing long sessions of development in VI variants as well of course. I have done that in the past, with a heavily configured NeoVIM, using some plugins and it worked quite well.
I would guess, that many people see it as an improper way of doing things, when one cannot accomplish a task directly in ones main editor, but needs to close it or open additional instances of it. The question automatically arises, what the problem is and why it cannot be done in the instance you already had opened. Was the previous instance somehow bad? Does an instance have a half-life period or something, so that it needs to be refreshed?
> Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff.
If I configure for myself in my free time the "optimal tool" and then just copy its configuration into my on-the-job tool, it is my time to spend and does not take anything away from the time writing code on the job. In fact, it even increases my productivity, compared to what some people do with VSCode instances being closed and opened and all that. No one else has to worry about how I personally spend my time. Even if I wanted to spend a few hours a day optimizing my own tooling in my free time, I should be allowed to do so.
If others want to work with less optimized tools or do not want to invest time into making their tool work as well, that is their choice. Doesn't make it less painful to watch in screensharing sessions though.
>>You can run Emacs as a server, for example on a remote host
> vscode is all about doing work the user should be doing. Nobody should be spending lots of times, in case of emacs that's often weeks to months of effort configuring and tweaking things that should come and work right out of the box.
Now you are just setting up a gigantic strawman. What kind of configuring around have you done, that took weeks or even months? Who would even be willing to do that, without looking for help from other people, who already have configured something similar? No single thing would take that long to configure. What you may be confused with it incremental improvement. Over the life of an Emacs setup, perhaps over a time-span of 10 years or so, it may well happen, that one spends weeks configuring things. Obviously not necessarily in one long marathon, but over time tweaking things. Half an hour here and there, to make life more pleasant and move beyond lowest common denominator functionality.
I agree, that one should not spend a lot of time configuring things before getting anything done, unless one has the time. However, default Emacs already is quite capable and I could easily work with that.
It would also only take me a minute to install a theme I like and perhaps magit. The return of time investment for magit is enormous, since I already know it, so I would install it right away. Hitting some M-x package-install RET magit RET takes less than a minute and makes every git interaction I am likely to need much faster.
The thing is, that with Emacs one gets things which one does not get in VSCode at all, no matter how long you configure VSCode. I personally expect more from my tooling and that is my choice. Who are you to decide what functionality I am to expect out of the box and what I am to not expect at all?
Honestly speaking the only real use case of vim/emacs style keyboard heavy editors I can see(having been a user for years) over vscode is use of keyboard macros. Which in modern context is rare enough to make a one off sacrifice.
But otherwise the only real use case for vi(m) is I see is server side editing, and its still the best tool out there for such tasks.
Neovim. It is lighter weight than either Emacs or VS Code but can still have pretty much all the bells and whistles. Definitely cool if you prefer to live in a terminal.
There are several GUIs for Neovim for various platforms [1].
I've used emacs for ~15 years now and never really get into org-mode, I have a directory of org files that I use for writing and keeping some kind of personal wiki but it's just a bunch of org files. I never successfully build a workflow around it.
I see that I'm missing something but I don't know where to start. Org-roam seems interesting.
Do you have any recommendation for how to use org-mode productively?
You don't necessarily have to build your own workflow around org-mode. If it works fine for you as it is, then that's OK. It is a fine markup format in itself. Finer than some others. Emacs has exceptional support for org-mode of course, which allows for good navigation within a document and things like folding headings and showing an overview.
If you want to go further, you can use things like including other org-mode documents at specific heading levels or even write thesis in it, falling back to latex when needed. There is also a citation format now in org-mode.
Another thing you could explore is org-babel. Try out the ideas of literate programming. A bit of "write once, export to other formats" like HTML make a blog post or similar.
I also use org-mode for some spreadsheet capabilities. Not really huge spreadsheets, but usable. For example I have working hours time tracking in org-mode using a table with formulas (a spreadsheet). Or I have a repository with recipes, where I can let it calculate amounts of ingredients, depending on the number of people who want to eat.
1. Learn org-agenda. And I do mean really learn it. I use a few of alphapapas amazing packages (org-super-agenda and org-ql). Learn the difference between just a TODO, scheduling, deadlining and tags. Don't overdo it on tags. Set up groups in the agenda for different things (STATE or TAGS, or something else)
2. Set up capture templates that fit you so you can instantly note things down in the right place
3. Learn org-attach so that you can have everything in your second brain
4. Do not fret to much about one large file or many small ones - use whatever you want. If you feel you want to change it, just change it. It is just plain text. This applies to everything in org-mode.
5. Learn org-store-link, which makes references to things like emails (even if they are moved/archived after the fact) or git or whatever to keep references.
I spent a lot of time getting this together myself. I empathise. But if I could not use org-agenda and the searches I have in the way I do, I would probably feel not get into org-mode either. Recall is key.
Maybe you don't need an org workflow. "Just a bunch of org files" is a totally fine way to use it. It's what I do too with some custom keybindings and bookmarks. I looked at some of the fancier stuff but they are not for me.
Like yourself, I don't do anything fancy. Just plain org files. However,
I do use org-journal [1], though, so I can ctrl-c ctrl-j to add a new entry, and have it automatically wired up for rotating the file monthly. I use this for adding new items and having speedy access. But that's it. I don't use Agenda or any of that fancy stuff, so don't feel guilty that you're missing out.
Probably going through Rainer König‘s org-mode tutorial series on youtube. I like that it’s all with vanilla org-mode. That way you can dig deeper into anything he’s doing in the org-mode docs or on worg.
I don’t have a very rigid workflow with it. Typically one org file will be a project I’m working on. I use custom “TODO” tags to show the state of items. I also love the table functionality. It basically replaces spreadsheets for me and it lives with the rest of the text.
I find people who like working with plain text tend to love Emacs or similar editor ecosystems. I really enjoy having almost all my workflows in one place, and once you get a handle on some keybindings you can manipulate text so fast and so cleanly it can be satisfying. I also know people who love things like shared editing of tasks, reminders with color highlights, etc. and they tend to not like Emacs. PS: I don't listen to music or plain text browse the Web in Emacs but I know people who do :D
I find the consistency and configurability great, but for me the killer features were being able to write elisp and kbd-macros to accomplish tasks that (most?) other editors can’t.
Modern conveniences include magit (the best git [porcelain] I’ve ever used) and cider, but I’ve been using emacs for 30+ years now and feel like for all but the first 6 months, it’s been an increasing time-saver and powerful lever for me to use.
That is an excellent observation. There is something special about living inside the same, consistent environment. You can reach productivity peaks that are impossible to achieve with an heterogeneous collection of tools.
It would help if you explain more what "accessible" means. What about it was a problem or left you dissatisfied.
BTW, the System Crafters Youtube channel has pretty good Emacs stuff - including for those with little experience. Although I've used Emacs for over a decade, I learned about fairly helpful packages via that channel.
I was an avid user and it's amazing how it's able to port abstractions between its various modes. For example, you can use an auto complete plugin that replaces text with regexes to rename a batch of files.
But nowadays I tend to prefer technologies that work reasonably well with a set of sane defaults. Emacs works really well when you are working on really hard problems and programming fringe things from scratch, but it pales in comparison to the productivity of simple no code tools that's been flourishing recently.
That's the experience for the kind of work I've been doing recently, which are mostly CRUD apps to support a business. It might not be true in other domains.
The key with Emacs is that it's an editor that grows: the close mapping between the editor and its code makes it more fluid and natural to extend than any other popular tool I've tried. It's a fuzzy distinction—not something you can put on a feature checklist—but it's made working with Emacs qualitatively different from working with other tools. While Emacs has certainly influenced other editors, none of the ones I'm familiar with have carried over this core philosophy.
That's my point. How did emacs influence this? Emacs is nothing like that. If anything, emacs has failed. Everything else is either proprietary or company/plugin based. And mouse based.
Imagine spending 8 hours a day for the rest of your life and you still want a cursor based popup telling you what you might or might not want to do instead of having muscle memory of what you do.
> Emacs had a GUI and mouse support forever on Windows.
Emacs did not invent the mouse cursor interface.
> It was “bloated and slow”.
This comes from not understanding how emacs works. Yes, it has games, no, it is not loaded until you load it. It means nothing, it does not mean bloat.
> I think we’re just missing each other here. The best features of eMacs spread to other editors.
I think we might - it's Emacs not eMacs.
> As for the scenario, I don’t see that as a hellish situation. I’ve been using vim for a while. Im actually ok at it.
Great! I love vim. In fact I used it for 15 years before switching. I would not be using emacs as my everything if evil-mode was not a thing.
> Do I regret learning it? Hell yeah. Lol. But at least I got vim mode to soothe the wound a little
Sometimes I think the same thing.. Everytime there is no vi mode I get annoyed. I try to be open to new software, but cua-mode (or default emacs keys) is not it for me.
I get your first point. I’m saying it was the most popular so that’s why it’s ideas spread. I’m only thinking of eMacs and Vim cus the editor wars were so big.
In the 2nd point, I’m just saying what the popular complaints were. I wasn’t trying to prove them either way. Just what the battles were about. I wasn’t there so I’m thinking like an archeologist here.
I know about the misspelling of eMacs but I’m on my phone. I don’t mean anything with it. Just too lazy to fix it.
There’s good stuff in Vim and I like it but yeah not gonna die and say “well! Glad I learned vim!”.
Live and learn. I’m still thinking what band Vim would be
This is a tough question to try to answer! I guess I'll cheat by asking one of my own: Can you characterize what about Emacs has put you off?
It took me a few tries too, back in the late noughties, before I finally found it "clicking" with me. I have a pretty good sense of what made that possible, but no idea if your experience is at all similar, so I hesitate to suggest anything in advance of getting a better sense of what I'm suggesting about.
I think it's the single tool for many uses thing. It's somehow more satisfying for some chef's to use, love, and care for a single knife to do everything in the kitchen than to buy 100 different chopping products. Emacs is the same way for people who love to build their tool and use it for everything. If you don't feel that way you probably won't see the point which is fine.
> It’s clear to me that there’s something magical in it, but I can’t seem to tap that magic for myself.
I love Emacs for some of its really nice features that I just cannot find anywhere else (and no Elisp knowledge is required). I'm not one for tech monocultures and try to diversify my tooling as much as I can, but Emacs is seriously good when it comes to so many things:
- Magit in Emacs is arguably the best Git interface in the planet. You can run simple operations and complex workflows with just a few keypresses.
- Note-taking with org-roam (https://www.orgroam.com/). This is the best Free note-taking system that I know of — it's like Roam Research, where you can have your own zettlekasten with backlinks etc. and it scales really well with a very large number of notes (it uses a SQLite database in the background). Notes, articles with images, I use this for so many things every day.
- Encrypted notes. Emacs handles encryption elegantly out of the box. You can encrypt entire documents transparently (by adding a .gpg extension, for instance) using symmetric or asymmetric encryption, and Emacs will get your keys from gpg all automatically. You can also encrypt small sections inside a larger document.
- Spreadsheets. I do all my personal spreadsheets in Emacs' Org Mode. It never ceases to amaze me how text formats can be so powerful. Works even on my oldest computer running Emacs from a decade ago.
- Emacs Calculator. This is like a mini-WolframAlpha inside Emacs. I can solve equations, perform operations on dates, convert units, track returns on investments, simple and compound interest, the list goes on. And it integrates really well with the rest of Emacs as well.
- Org Mode. This is possibly the best designed markup language. I take all my notes in this. You can have inline images, spreadsheets, code blocks with inline execution etc. Its support for literate programming is really awesome: it's like Jupyter Notebooks but for any language. (Emacs' Markdown support is really awesome and powerful, as well, with its previews and table handling etc)
- Gorgeous typography. I run Emacs as a GUI app at all times, and it renders all my typography (proportional or monospaced) gorgeously which makes it a delight to look at and use (Ideal Sans + Verlag for notes (org, markdown, reST etc), Cascadia Code for coding with programming ligatures enabled). This is all in the raw text, not just in the preview like other editors.
- Powerful macro support.
A few other miscellaneous things that come to mind:
- Powerful window management. I can split panes vertically, horizontally, and undo and redo my window layout, all out of the box. This makes working with multiple files a breeze, especially when you have to look at some of them at the same time, and/or move to different layouts on the fly.
- Navigation and text-editing at a higher level of abstraction. With Emacs, I can navigate not just in the normal ways (by lines, characters, words etc.), but in various other context-dependent ways: e.g. Emacs understands sentences, functions etc. and I can navigate, delete, select, and manipulate text at a much higher level, allowing me to work with Emacs in ways that traditional editors cannot match.
- Calendar. I use this for various things, like quickly finding out when sunset is. It can also tell you phases of the moon etc. if you need that, all out of the box.
- Email using mu4e. Emacs can work as a beautiful mail client. I used to use this several years ago with mbsync (isync). It's surprising how offline email can let you search through all your emails literally instantly.
And there's so much more depending on what you're looking for :)
Emacs is like this retro piece of software that is paradoxically highly modern at the same time and actually better than the status quo. (It's snowing outside now. Let me go ahead and run M-x fireplace in my Emacs ;)
I feel you and you are not the only one. For me it was the time sink every time I wanted emacs to do something different, it was fun for a while (3 years) but now I want to spend my time elsewhere. Also Elisp kinda sucks.
