I wish someone could write a "The Good Parts" book for Emacs. Even after reading the manual twice, I'm still overwhelmed with the API and forget even the most basic configuration options after a month of inactivity.
FWIW, for just "using" Emacs, I wrote a number of keyboard-driven menus for different modes called Casual. Read all about it here: https://github.com/kickingvegas/casual
For understanding Elisp, I wrote an "Elisp Cheetsheet for Python Programmers" to help as a reference.
There's truth to this. Emacs is large. I tried RTFM twice, thrice .. not skimming, taking time. And even then I learn later that there was some feature in it that I completely missed. And it's a common joke in the community "I've been using emacs for <N> decades and I didn't know that...".
Blessing and a curse ? Maybe they should rebrand emacs as a universe and not an editor.. so that people know there are many galaxies to explore
The thing is that you don't really learn Emacs. Emacs is just an interface to programs written in Elisp that happens to have editor-like functionality out of the box. There are specific conventions it follows, and Elisp has its own set of quirks and a steep learning curve if the user is not fluent in other Lisp languages, so those can be challenging to learn. But boiled down to its core, there's not much to Emacs itself. It's actually a pretty bad editor OOB, but that might be subjective.
What is more challenging is actually customizing Emacs to suit your own preferences, which is the main reason you would want to use it. Deciding which external packages to install, how to use and customize them, and writing your own packages. That is a lifelong endeavor and learning experience, just like programming. So it's to be expected that someone might be a long-time Emacs user, but not be aware of some of its features. You're not expected to know everything, nor do you need to. Just learn as much as you need to make it useful for you. Essentially, every Emacs installation is different, since it's purpose built for a specific use case according to very specific preferences. There's no singular "Emacs". And that is a beautiful thing. :)
I was really talking about the builtin libraries (listed in the core manual). That in itself is a challenge. The surface is huge. Not a critic per se, I've been using emacs for 25 years, I'm just reporting.
Saying this as somebody who's been coevolving with emacs for 20 years already. Oh, all the little bits of lisp, all the mechanical memory, all the IDEs that came and went...
Generally speaking, unless you're doing something weird (typeset IEC ladder!), proprietary (code completion for Aveva Quickscipt!), or right on the cutting edge, someone has figured out a way of doing what you need in Emacs. You just have to identify the pain points first. That's harder than people think.
I have the same feeling with Vim after using it for like the past 10 years professionally. Granted, it is much smaller, but for instance editing multiple files using just stock config is surprisingly undiscoverable. It comes with the whole buffer mechanism, which is certainly powerful, but I guess that 99% of newcomers just want to open tabs and go left/right, not to learn set of byzantine commands like :rewind or :last.
At this point, I believe that newcomers should jump straight to Neovim and file manager plugins, than deal with the stock stuff. That's just one thing out of many.
> but I guess that 99% of newcomers just want to open tabs and go left/right, not to learn set of byzantine commands like :rewind or :last.
There's nano and multiple other editors for that. You want vim for a more powerful interactions than go left and write.
My need for vim is to open a file, go the the place I want to, quickly edit it, and go back to what I was doing (which is reading and thinking). Editing is just a short bust instead of being a continual activity.
Another annoyance with editors like VS Code (and the like) is how tedious to have information. Every file is in own tab (even though you can show more at once, but that's tedious). So you are always flipping back and forth. With vim, I can have everything at once in front of me, and once I have a clear line of action collapse it to the few (2 or 3) I need. Also quickly.
Vim and Emacs are for those that really needs them. There's a lot to learn, but that's because there's a lot you want to do.
Emacs is the type of environment you need to immerse yourself in and build an intuition for. There's no shortcut for that. If you can't spend a couple hours a day for a few months using it, you're never going to feel at home in it.
As a longtime emacs user, this perfectly summarizes what is most awful about it! It makes me cringe when people wag their fingers to correct the "misperception" that emacs is merely a great text editor and IDE, but rather a programmable elisp application platform. In reality, vanilla emacs with only a little bit of configuration (and as with any other editor, substantially more tinkering with installation and configuration of supporting binaries), provides a really great programming environment for almost any type of application.
There's a lot of good text editors out there, though. Vanilla Emacs with some tweaks is decent, sure, but if all you do is use the basic editing commands then you'll probably feel more at home with a different editor.
Look at the tutorial - it does everything it can to encourage you not to use the arrow keys or PGUP/PGDN. No, you're supposed to learn all kinds of whacky key combinations instead. That's all for a good reason but it's hardly encouraging for new users faced with the choice of doing things the "proper" way and building new muscle memory vs. using the keys they already know.
If all you want is a decent editor to get some work done without having to spend a fair amount of time learning the editor itself, Emacs probably isn't the best choice.
(To others reading this comment: Emacs editing commands have a hierarchy of sorts. It's powerful, and context-aware. But it requires you to internalize things like CTRL-f to move the cursor to the right. Unless you make the effort to learn them - or use evil-mode - you miss out on a good chunk of what makes Emacs so great for editing.)
It reminds me of the "actually a monad is" explanations. Yes monads are wonderful mathemagical infinityburritos that you can spend phds studying, but they also just happen to be very practical and useful even when you don't know you're using them and even if you have no emotional reaction to the name Simon.
It's also a great file manager, a good shell environment, a document viewer, a mail viewer and composer, a process manager, a music player, and you can play games in it. All powered by elisp.
> forget even the most basic configuration options after a month of inactivity
So do I. ChatGPT4o and the like of course do not forget, and they've read more documentation, library code, and message forum postings than any human could. They know all the five or so ways to initialize per-buffer variables and will write you little snippets of Elisp to add to your .emacs or .dir-locals.el or per-file headers/trailers.
So, if Org-mode or multi-occur aren't doing what I want, and `M-x info-emacs-manual` doesn't make it obvious, ChatGPT4o is my next recourse.
Doom Emacs (https://github.com/doomemacs/doomemacs) essentially serves this purpose with its curated, modular configuration and excellent documentation that focuses on the most useful parts while hiding complexity.
Doom is really cool and I appreciate the devs’ hard work. It’s seriously impressive.
But. Doom is an uncanny valley for me. It looks like Emacs, but feels like something else entirely, something unlike I’ve ever used before. If you want to use all the things available inside Emacs without learning the “bare” version, right on. But if you actually want to learn Emacs, in my opinion, Doom isn’t it. It’s its own thing, and it’s a fine thing, but whatever it is, to me, it ain’t Emacs.
Doom is in all respects Emacs. It's a relatively thin layer of abstractions on top of Emacs. I've lived through a fair share of emacs.d bankruptcies until finally settling down on using Doom, and I almost don't even use "the official" modules — I use the core of Doom with a set of my own modules. You can easily scroll through early-init.el to understand what Doom adds on top of vanilla Emacs; what's there really to even "learn about"?
I have thought about rebuilding my config from scratch once again, with all the knowledge I gained over the years, but every time I think about it, I conclude that I inevitably would end up replicating some nice macros that Doom has, which do considerably reduce otherwise unavoidable boilerplate I'd have to write.
Doom may have improved discoverability of Emacs — a major complaint of newbies known for decades — but it can't magically make Emacs "something else entirely". I don't even get what you're talking about, it's like finding any complex package written in Elisp and lament that it doesn't even feel like an Emacs thing.
It's worth noting that you'd have to pay for the book only once. Every new edition you'd get for free. Mickey keeps the book updated and relevant for every new release of Emacs.
I'd like to take this question one step further: When do you think is an appropriate point to take a sabbatical? After working for a year, two years, three etc. The reason I'm asking is that junior developers might feel the need for a break earlier in their careers compared to experienced devs.
"Sabbatical" after 1 or 2 years is a joke right? It's no wonder companies are looking hard to ditch entitled software engineering labor as quickly as they can.
I think employers, already prone to looking askance at resume gaps, might be particularly put off by that (no counter example of long commitment, no way to brush it off as a better offer or need to move). I personally wouldn't risk it until I had four or five years at one company but others may have more confidence.
You might be able to get extended unpaid time off without leaving. My team has an unofficial policy that you can take up to about a month unpaid (not every year).
Come on, this is the kind of project that could be done by an intern in a day or two. Not much of a waste and it's nice to be able to access models without login or history.
Amazing timing, I was just getting into open source these days and I have the same feelings you described in the beginning when I make a contribution.
The essay kindly tells us how you feel right now, proud but tired and contemplating. IMHO That’s always going to be the case for hard working people like you, but still it is interesting that you kept pushing even though you didn’t feel comfortable and confident doing all those things you were unprepared for. And even though you were able to overcome all those challenges, you still doesn’t sound satisfied with you current situation. Maybe that’s because you have even bigger dreams?
I think you’ve done an amazing work and deserve a long rest. I’m sure it’ll be bit harder for people depending on you, but they’ll get used to it eventually and you’ll feel more relaxed and maybe more fulfilled by giving yourself some space and time.
I knew other people felt the same way! There was this coffee shop I always hanged out, which recently "permanently closed" as the owner died RIP. It is really hard to explain that feeling, which I literally can't. But awesome idea!
Yes! This! The code should be so boring it's never a point of discussion. This implies several things - for example when bringing in a new person, it should be straightforward to teach them how to work with codebase.
Other implications include naming conventions, sufficient amount of documentation, what architectural patterns to choose (if you need to do something that even hints of accidental complexity you need to have really good justification for it)...etc.
> The code should be so boring it's never a point of discussion. This implies several things - for example when bringing in a new person, it should be straightforward to teach them how to work with codebase.
