Hacker News Reader

Overall, I think it's a pretty fair assessment. Emacs is dense, obscure and what is these days called "opinionated". You gotta remember though, that Emacs is from mid 70s. There's a lot of legacy there, but also a lot of refinement. Lots of brilliant people have spent a lot of time improving it over the years.

You shouldn't think of Emacs as an editor; it's a text processing system. In other words it supports lots of workflows of which IDE is only one.

I also use it as a knowledge management system (org-brain) and task tracker (org-mode). It helps me manage my days because it hooks into google calendar. I manage my bugs via a JIRA integration, read my mail through it and now I'm gonna check out the IM mode :)

> "opinionated"

I feel this term might need to be officially dead and buried. If something as customizable as emacs is deemed opinionated what does this even mean? For chrissakes there are people that consider emacs to be a better vi implementation than vim.

Well, there are lots of customizations doable (I’m still rocking my .emacs from the 1990’s going through several platforms, Linux→MacOS→Linux, refined over the years with custom functions etc.) but to name a single example: my keyboard does have a Find key, and I tried mapping isearch-forward to it instead of the default CTRL+S. That’s trivial, but then, you know how you can press CTRL+S again to go to the next result? Well, that key combo is hardcoded in LISP. So yes, you technically can remap isearch-forward, but in a useless way.

> that key combo is hardcoded in LISP

isearch-forward turns on a minor mode that has it's own keymap

a snippet from isearch.el:

  (defvar isearch-mode-map
    ...
    ;; Several non-printing chars change the searching behavior.
    (define-key map "\C-s" 'isearch-repeat-forward)
    (define-key map "\C-r" 'isearch-repeat-backward)

hence to redefine C-s, to, say F12:

  (global-set-key [f12] 'isearch-forward)
  (define-key isearch-mode-map [f12] 'isearch-repeat-forward)

& so on

I don't see what is the problem here

I see, thanks for the correction.

What HNer henry_flower neglected to state explicitly in his helpful comment is that it is false that pressing C-s to go to the next result is hardcoded in some Emacs Lisp function. I just wanted to say that in case non-Emacsers don't know it's implied by what Henry did say. (What he said is much better than just "that's not true!", he also tells you how to change the C-s key that goes to the next match.)

I realize now that I misused the term “hardcoded”, thanks.

I hate to tell you this, but it's not Emacs that's slow and clunky, it's Spacemacs. I dumped Spacemacs and spent a couple days building a new config with everything I used from Spacemacs and it is a good 10x faster.

It shouldn't be surprising, seeing as Spacemacs development ground to a complete halt (no new releases) something like two years ago.

Spacemacs is a neat demo of what is possible with Emacs but it adds a TON of complexity and bloat. I found it much harder to troubleshoot and it didn't keep up with the rest of the ecosystem, and it's the rest of the ecosystem (and Emacs Lisp) that make Emacs so special.

Agreed. I started with Spacemacs, which showed what is possible in Emacs. But it is so horribly slow and breaks so often that I couldn't use it more than a few weeks. Then I started with a blank init.el and just added packages (with use-package) as needed. Now it's fast and it still has the functionality that I need, things also rarely break (and thanks to Nix I can always roll back). The main idea that I stole from Spacemacs is the use of spacebar shortcuts (via general.el).

The thing about Spacemacs many people don't get - it does not liberate you from learning Emacs internals. The good thing about Spacemacs that it simplifies one of the most challenging things about Emacs - discoverability.

The hardest part of Emacs is to learn what Emacs can do, what it offers. And many gems are hidden under so many layers, that people may not even know about them after decades of using Emacs every single day.

And Spacemacs can be fast and predictable. But you need to know where and how to tweak it to make it so. For the past few years of me using Spacemacs, I had maybe three of four incidents when after updating things, something would break in a way that it would take me longer than ten minutes to find a workaround.

> The hardest part of Emacs is to learn what Emacs can do, what it offers.

Nah, for me the hardest part is finding out about all the things it doesn't do. Unless you code it. Maybe you find some half-arsed packages, but they might just make you more frustrated.

For example, I still haven't found a way to do vim-like completion. I still haven't got a good cscope interface that doesn't crap all over my windows (a common problem for many things in emacs, not just xcscope). I still haven't found a way to make my custom keybindings just work everywhere; every so often I happen to end up with focus in a window where, for example, my normal window navigation bindings don't work and I'd have to go out of my way to fix it.

> I still haven't found a way to make my custom keybindings just work everywhere; every so often I happen to end up with focus in a window where, for example, my normal window navigation bindings don't work and I'd have to go out of my way to fix it.

The easiest way to do this is to use `bind-keys' (specifically, the one with an asterisk after it, which HN markup won't seem to let me use without creating italics instead), which creates a global map for your personal key bindings that override other bindings (so, use it thoughtfully, and remember that `describe-personal-keybindings' will list them). It's best used in the `use-package' macro, like:

    (use-package ace-jump-mode
      :bind* ("C-." . ace-jump-mode))

My bindings need to be state-aware, because they are evil. So a simple global override is actually not quite enough..

In that case, I recommend using `general`, which is designed to make configuring EVIL keymaps very easy. It also provides a `use-package` keyword. I use it for all of my keybindings even though I don't use EVIL.

https://github.com/noctuid/general.el

As a devoted emacs addict, I can attest that plan old emacs is also pretty slow and clunky, though I could easily believe spacemacs is even worse!

My dream editor would combine the flexibility of emacs w/ the speed and quality of sublime.

>As a devoted emacs addict, I can attest that plan old emacs is also pretty slow and clunky

it's true in the sense that it's true for almost anything once you start to add a plugin or two or add personal customizations.

The only thing for me that is actually consistently, superfast is terminal vim without any plugins. Which is too barebones for my daily use.

In a realistic, daily working environment with all my stuff loaded emacs is clunky, but not necessarily slow. It's honestly still pretty responsive.

Even just basic text rendering in emacs is slow!

Three examples:

I use the windowed Mac version most of the time, and touchpad scrolling is so slow that it's basically not a reasonable way to get around a file. Compare to Sublime, where it's silky smooth, and you can get an almost physical feeling of where things are, which makes zipping around using scrolling very effective.

I run my shell inside emacs (which is super nice -- how do people survive not having easy immediate access to command output)? But if a command is going to generate a lot of output (e.g., if I have the misfortune to be running mvn), I'll need to either drop back to terminal or redirect the output to a file, or be content with my command slowing down 100x to wait for emacs to render the output.

Try opening a file that happens to contain a very long line (this happens sometimes w/ generated code, or json data, or ...). Emacs will basically freeze, due to some N^2 in line length algorithm somewhere.

It's no easy task, but I do think it's possible to make something w/ the near-infinite, excellent flexibility of emacs, while also hitting a much higher speed and quality bar.

Scrolling sounds like a terrible way to get around a file. I'd much rather be presented with a prompt to go to a named "section" with completion (an actual section in a prose document, or a function definition in a program), or to search for some text. Or, if I don't have a specific target in mind and I want an overview of the file, I prefer pagination to scrolling.

But... I wonder how much my preference is conditioned by years of Emacs and its subpar scrolling? My preference for pagination+search extends to other software; to browsers, for example (spacebar or ctrl+f over mouse-wheel), but is that just a habit I got from my constant Emacs usage (I typed this comment in Emacs)?

Exactly, it's hard to miss what you haven't had!

In emacs, I mostly navigate around by searching, or sometimes by outlining (hide all lines that aren't a definition, move to definition, unhide).

But I do remember before I became an emacs addict, and there was something very nice about having a physical sense of your file layout. If you have that sense, scrolling can an efficient way to navigate a file (well, up to a certain size, anyway).

And I think there's something valuable in the almost subconscious feeling for the layout of the file you get as you scroll thru it.

When I'm mostly in emacs, my sense of what a file "is" is much hazier, because I'm just warping from one place to another.

(On the other hand, maybe the entire concept of a file as a linear progression is antiquated for source code...)

Quality? I think Emacs (for what it does) is a product of superb quality. I just checked - I pull over 400 packages (including built-ins). Can you imagine Sublime, VSCode, or Atom with 400 plugins installed? I don't even know if you can find that many useful plugins for them, but even if you do, I think at best it would just hang them indefinitely.

And these are not 400 "dead-weight," useless packages. These are real programs that very often tightly integrate with each other. Some of them like Magit and Org-mode are quite serious products by themselves.

Sure, there are decades-old issues in Emacs, and they are slowly, steadily being worked on. The problem with long lines is getting fixed. JSON performance got improved with jansson. Elisp native - some people reported a 300% speed boost. Rendering improvements with Cairo - no longer experimental; Native line numbers are in the stable version of Emacs; People today discussing using Tree-sitter for parsing, which would significantly improve syntax-highlighting. And many other things are slowly being improved.

Things move slowly in the Emacs world. We have many smart people, but we don't have enough of them to contribute and move things fast.

No argument that emacs is getting better.

But I'm not sure it will ever be what I would consider high-quality!

I think it's just the nature of a huge system implemented (mostly) in a dynamically typed, dynamically scoped (!) (though, happily, more and more less and less) language to be partly broken all of the time.

And, to be fair, most of the bugginess is not emacs per-se, but in the various packages and their interactions -- but what is emacs, really, other than a platform to run the packages?

So here's some random problems I have (I have a long list, and occasionally I try to fix one; the list is growing):

- After I run a python shell for a while, bash shells stop asynchronously showing command output; the shell just hangs until the command completes.

- There's an awesome mode iedit that lets you edit all instances of a symbol. Sometimes, for certain sequences of characters, instead of correctly performing the edit, it inserts gibberish.

- There's an awesome mode grep-ed that let's you edit grep(†) results inline; very convenient. Except for when it very rarely, randomly decides to garbles the files.

(† Or even better ripgrep -- random shout out to truly fantastic piece of software!)

- The afore-mentioned iedit mode doesn't work w/ the delete-horizontal-space editing command. (All other commands, yes, just not that one, for some reason.)

- There is a mode dumb-jump that jumps to symbols. There is an emacs feature to soft-wrap lines. Dump-jump doesn't work when jumping to a symbol that's on a wrapped line.

- To work around a rare but tricky race condition, emacs shell mode at some point added a built-in 1-second startup delay. I lived w/ annoyingly slow shell starts for months before I finally tracked it down, only to find out it was on-purpose terrible kludge!

- The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets really long.

&c &c &c.

So while I spend most my time in emacs and have great affection for it, I definitely don't feel like it's a high-quality experience. I'm constantly running into little bugs.

To be fair, most of my arguments are with 3rd-party packages and their interactions, not emacs per-se. But emacs w/o 3rd party packages would be like a non-fat decaf latte: what's the point?

(P.S. Very excited about the possibility of fixed long lines & tree-sitting parsers!)

> I think it's just the nature of a huge system implemented (mostly) in a dynamically typed, dynamically scoped (!) (though, happily, more and more less and less) language to be partly broken all of the time.

To be clear, Elisp has had lexical-binding for about 8 years now.

> After I run a python shell for a while, bash shells stop asynchronously showing command output; the shell just hangs until the command completes.

That's very strange, indeed. See if you can reproduce with emacs -q.

> There's an awesome mode iedit that lets you edit all instances of a symbol. Sometimes, for certain sequences of characters, instead of correctly performing the edit, it inserts gibberish.

iedit is great. I've never seen it insert gibberish or misbehave in any way.

> There's an awesome mode grep-ed that let's you edit grep(†) results inline; very convenient. Except for when it very rarely, randomly decides to garbles the files.

Haven't heard of grep-ed. Maybe you're thinking of wgrep? See also occur, which can also perform edits. In fact, there are probably at least 5-10 packages which implement such functionality, some of which are built-in.

> The afore-mentioned iedit mode doesn't work w/ the delete-horizontal-space editing command. (All other commands, yes, just not that one, for some reason.)

It would be helpful to report that issue so it could be fixed.

> There is a mode dumb-jump that jumps to symbols. There is an emacs feature to soft-wrap lines. Dump-jump doesn't work when jumping to a symbol that's on a wrapped line.

That's unlikely. If that ever were the case, it's probably fixed by now, because dumb-jump is under active development, very popular, and widely recommended, and that would be a very basic problem. Besides, I can't imagine how being on a wrapped line would affect it, because Emacs commands that read from the buffer aren't affected by visual-line-mode.

> To work around a rare but tricky race condition, emacs shell mode at some point added a built-in 1-second startup delay. I lived w/ annoyingly slow shell starts for months before I finally tracked it down, only to find out it was on-purpose terrible kludge!

Try ansi-term instead of shell.

> The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets really long.

Extremely long lines have been a problem in Emacs for a long time, however Emacs 27 includes so-long-mode, which mitigates it.

Thanks, I do appreciate the tips.

Like I mentioned, these are just a couple problems from a longer list. Occasionally, I pick one and (try) to solve it. If I tried to solve them all, I wouldn't have much time left for anything else. :-)

My more general point is Emacs is pretty janky.

I also don't think it's inevitable -- it's possible to make something that offers the awesome flexibility of emacs, but w/o the quality issues. Who knows, maybe Emacs itself will eventually evolve in this direction.

(Re a couple of your specific points:

- I just checked, and 36% of the files in my site-lisp directory are using lexical scoping.

- Dynamic scoping can be handy! Here's (incredibly nasty) my fix for the hard-coded 1-second delay in shell mode:

  (flet ((sleep-for (&rest args) ())) ;; redefine sleep-for since shell calls it on purpose, guaranteeing a 1s startup time...

The fact that such a fix is needed, on the one hand, and that such a fix is possible, on the other, are emblematic of the both cultural and technical reasons that emacs is not more robust.)

> Like I mentioned, these are just a couple problems from a longer list. Occasionally, I pick one and (try) to solve it. If I tried to solve them all, I wouldn't have much time left for anything else. :-)

> My more general point is Emacs is pretty janky.

Well, for various definitions of "janky," perhaps. But I think your problems are mainly from third-party packages and your init file, not from Emacs itself. It's very common for Emacs to get blamed for badly written packages and code copied from random places. Such problems usually disappear by running `emacs -q`.

> I just checked, and 36% of the files in my site-lisp directory are using lexical scoping.

Maybe you meant the `lisp` directory? `site-lisp` is for site-local files, e.g. ones provided by the distro packagers and sysadmins, not by Emacs itself. I have a single file in my /usr/share/emacs/26.3/site-lisp directory, `subdirs.el`, which contains, in its entirety:

    (if (fboundp 'normal-top-level-add-subdirs-to-load-path)
        (normal-top-level-add-subdirs-to-load-path))

In contrast, /usr/share/emacs/26.3/lisp contains 258 .el.gz files, from Emacs itself.

About the same percentage as you mentioned use lexical-binding, yes. Patches welcome, I'm sure, although I wouldn't expect a noticeable performance improvement by changing them to do so.

> Dynamic scoping can be handy! Here's (incredibly nasty) my fix for the hard-coded 1-second delay in shell mode:

That is pretty nasty. ;) There are two better solutions:

1. Use ansi-term instead of shell. ansi-term is the better shell package included in Emacs. AFAIK there's no reason to use shell over ansi-term. Just call `M-x ansi-term RET` instead.

2. Generally, use advice rather than `flet`. But I can't recommend advising `sleep-for`, as that would be likely to cause problems.

And FYI (you may already know, but in case not), with lexical-binding, you would have to use either advice or `letf` with `symbol-function` to override functions like that.

> The fact that such a fix is needed, on the one hand, and that such a fix is possible, on the other, are emblematic of the both cultural and technical reasons that emacs is not more robust.)

FWIW, there is no call to `sleep-for` in my Emacs 26.3's `shell.el` file. I suspect you have a configuration problem, or perhaps you installed an Emacs that was packaged poorly, with ill-advised patches applied.

On the one hand, you're absolutely correct that most of my problems are in 3rd party packages, my own customizations (perhaps), and their interactions.

But on the other hand, emacs w/o 3rd party packages and personal customizations isn't really Emacs!

So I think it's fair to critique the quality of the software you end up with in practice, as a normal user of Emacs. Perhaps I should say the "Emacs ecosystem" tends towards jankiness, rather than Emacs itself, per se.

> site-lisp vs lisp

I meant my personal collection of 3rd party packages I have installed, which for some reason I call site-lisp, perhaps an abuse of the term!

My thinking was recent 3rd-party code wold be a better pulse-check of current practice than emacs itself, which I'd expect to have a lot of older code predating lexical scope. Interesting that they're about the same though.

> FWIW, there is no call to `sleep-for` in my Emacs 26.3's `shell.el` file

It turns out it's in comint.el, in (comint-exec). Here's the code:

  ;; Feed it the startfile.
  (cond (startfile
   ;;This is guaranteed to wait long enough
   ;;but has bad results if the comint does not prompt at all
   ;;       (while (= size (buffer-size))
   ;;         (sleep-for 1))
   ;;I hope 1 second is enough!
   (sleep-for 1)
 ...

> But on the other hand, emacs w/o 3rd party packages and personal customizations isn't really Emacs!

Certainly it is! There are many users who have used Emacs for decades who have only a handful of lines in their init files and no third-party packages.

> So I think it's fair to critique the quality of the software you end up with in practice, as a normal user of Emacs. Perhaps I should say the "Emacs ecosystem" tends towards jankiness, rather than Emacs itself, per se.

Yes, I think you should say that instead; that would be more fair and accurate.

Elisp is a forgiving language, and Emacs is a forgiving environment, so low-quality code is not always "punished" by failing to compile or run. So, as with any software you would run on your computer, you should use discretion.

The good news is that the quality of software in the Emacs ecosystem is steadily improving. MELPA is upholding higher standards for packages, and more tools are being made to catch poor-quality code and encourage best practices.

> I meant my personal collection of 3rd party packages I have installed, which for some reason I call site-lisp, perhaps an abuse of the term!

Ah, I see. Not necessarily an abuse, if you are your own sysadmin, I guess. :)

> It turns out it's in comint.el, in (comint-exec).

Thanks, that's interesting. I guess there must be some interesting discussion on emacs-devel about that from years past. I wonder if that could be improved.

> Certainly it is! There are many users who have used Emacs for decades who have only a handful of lines in their init files and no third-party packages.

...

> Yes, I think you should say that instead; that would be more fair and accurate.

Makes sense, & will do in the future!

> The good news is that the quality of software in the Emacs ecosystem is steadily improving. MELPA is upholding higher standards for packages, and more tools are being made to catch poor-quality code and encourage best practices.

Good to hear. :-)

Doom emacs I think demonstrates that have you can something all around nicer both form and function than spacemacs with absolutely amazing performance. My emacs install on a Sandy Bridge toaster with hundreds of packages configured is ready to go in about half a second.

It is an accurate and absolutely fair assessment (from a perspective of someone new to Emacs), and I wouldn't even try to convince you otherwise. Probably nobody has ever fallen in love with Emacs right away after trying it for the first time. There's no "honeymoon period" with Emacs, and there's no "Learn Emacs in 21 days."

Getting Emacs is a journey. For me, it took years to get to the point where I discovered just enough of it to say with absolute certainty. In essence, there's simply no other software product in human history that has that level of extensibility.

Oh, I was not too fond of it in the beginning. I hated people praising it all the time. I hated watching people doing some mind-blowing tricks of text manipulation or some other productivity stunts. Just like you, I've deleted it with a promise never to try it again. But unlike you, I reinstalled, tried, and angrily deleted it again, and did that numerous times.

Before Emacs, I've used several different editors and IDEs - from Borland Delphi and C++Builder and a bunch of different versions of Visual Studio to Sublime Text, Atom, Vim, and finally IntelliJ. OMG, I loved IntelliJ. I used it for about seven years quite extensively. I used it to the point where it became my hobby to find some poorly documented features of it. I've submitted a ton of requests on YouTrack for improvements and bugs I found. I still get email notifications for those of them that never got addressed, yet people see them and upvote them, even after so many years.

Somehow, my curiosity kept bringing me back to Emacs. Luckily, every so often, I would meet someone who'd show me some cool Emacs stuff, and that would make me angry again - "am I really so stupid that I can never understand this piece of s... oftware?" Countless times I would try to "fix" my Emacs config, because "why this shit doesn't work?".

At some point, I had to keep at least three different things open all the time - IntelliJ (my main driver), Sublime/Atom/Vim, and Emacs. And one day I decided - I have to do something about it. There was too much frustration from context switching. And since I already knew IntelliJ very well, I decided to give Emacs a serious stress-test.

I promised myself that for one week, I would try to use Emacs and only it. And whenever I would need to do something, I would find a way to do that in Emacs and ignore my temptation to go back to the warmth of my cozy IDE. The first week was tough, but I survived. The second week was exhausting. After a few weeks, I was almost comfortable. I kept downloading and installing IntelliJ EAPs for some reason, maybe out of fear that one day Emacs would break so badly that I would have to abandon it again. Or maybe because I was sure, one day I will find that pretty major thing that Emacs just can't do. Oh boy, I've proven to be wrong. Over and over again. It turned out - not only Emacs could do anything I needed, it would do it better. A few months later I got a new job, a new computer. And at some point, I realized that I've never installed IntelliJ, but I'm still very happy. I have outgrown it.

- "Cool story, bro," you might say, "but how does that help me?"

I don't know the definitive answer. Emacs is an incredibly hard sell to uninitiated. You have to be tenacious. But I know for sure - learning Emacs is absolutely worth the initial pain and suffering.

Emacs is fast and responsive in my experience, as I'd expect relatively small software to be; the old jibe was Eight Megs And Constantly Swapping, after all, but if your system can't devote eight megs of RAM to a text editor you've got other problems.

Are certain extensions slow? I won't say "no", because there's a ton of them out there, which is probably part of the problem here: My Emacs isn't your Emacs, my set of extensions and modifications isn't yours, and, therefore, my experience with Emacs isn't yours.

I don't find Emacs clunky, but I like chorded UIs and I know the basic Emacs workflow by muscle memory at this point. I can't say if it's clunky or not because my hands know it, so I don't think about it anymore. There was a time when I didn't know it that well, so it was clunky for me, but I would have gone through the same period with Vim.

My big reason to stick with Emacs is that it's stable. There's a stable core, composed of C and the core Emacs Lisp libraries, which is unchanging, so my muscle memory is never punished by someone deciding that keys should work differently now so we're going to improve all of them you're welcome. I can keep my configuraton files and my hands and everything continues to work, which seems to be counter to the trend of modern productivity software.

Clunky? Yes (adorably so for us Emacs lovers, but I understand this can be problematic for new users). But slow? That doesn't sound like Emacs, it's probably some misbehaving third party package included in Spacemacs that made it feel slow.

Also, it doesn't seem quite fair to blame Emacs for inscrutable interaction between third party packages, rather than blaming the packages involved in the interaction.

If you do ever try Emacs again, hold off on using third party packages. The bar for getting a package admitted into Emacs is higher than just putting it up on GitHub, so naturally the built-in packages tend to be more robust on average (which is not to say there aren't many excellent third party packages, there are!, but it's reasonable to be more weary of them than of built-ins).

Also, could you say a bit more about how you found the Emacs documentation puzzling? I love the documentation, it's thorough and very readily accesible. I don't use IDEs (because I have no use for them) but if their documentation is even better than Emacs's I might play with one just to enjoy the documentation.

(Finally, if you meant Spacemacs's documentation ignore the previous paragraph: I have no idea what its documentation is like, I was only talking about Emacs.)

Emacs OOTB sucks and some of the most useful packages will never be built-in, because developers don't want to deal with license assignment and locking themselves to the slow release cycle of Emacs. Also the community can be discouraging.

"Emacs OOTB sucks" People say that, and those people are entitled to their opinion. (A word of warning: I think many people who say that are not actual Emacs users.) I'll keep happily using vanilla Emacs while people complain about it, though.

Of course, I don't really use it OOTB, I mean, I do have a configuration. My 700 line init file installs some 20 third party packages from MELPA, and changes a lot of defaults. I've also written about 1200 more lines of Emacs Lisp distributed among some 25 tiny packages I use. But I did start with Emacs OOTB and never thought it sucked, I thought instead, over and over, that some minor aspect could do with some tweaking. :P

And not locking yourself to Emacs's slow release cycle is a perfectly valid reason for not wanting your packge to be built-in. I don't think there is anything wrong with the fact that many excellent third party packages will never be built-in.

> 700 line init ... written about 1200 more lines

"happily using vanilla Emacs" indeed.

Well, you're right, it's not so vanilla anymore. :)

But that has accumulated over the course of about 10 years, so its really not a lot. And the possibility of having everything just the way I like is what drew me to Emacs in the first place! A shorter config would be an indication that either (1) I happened to like everything exactly the way it was by default, or (2) annoyances can't actually be fixed. I don't think any software could fall into (1) (right?, there's always something you wish were slightly different, or something you want to automate) and Emacs, unlike most programs, does not fall into (2).

Also if you saw my configuration and compared it people who use Doom or Spacemacs, or even just Helm or Ivy, you'd think my Emacs is very vanilla.

re: The documentation, I found the standard Emacs docs good enough to learn high-level Emacs concepts and such, but whenever I went searching for the nuts and bolts of how to configure specific bits of functionality, the documentation I stumbled upon (it's rarely easy to discover) either a) assumed a high level of proficiency and understanding of Emacs internals, often accompanied by (or consisting entirely of) large snippets of Emacs LISP b) was written in a kind of reference style that failed to give much context or help the user along in any way, or c) would be contradicted or superseded by some other piece of documentation, usually because of subtle package incompatibilities (probably exacerbated by Spacemacs in my case).

The Emacs community does not seem to have converged on a particular documentation idiom so there is a wide range of documentation quality for various configuration use cases. Most of the time I ended up finding bits and pieces of answers on Stack Overflow or other message boards, and proceeding with a lot of trial and error. That is fun sometimes, but not all the time; it was a rare experience when the documentation really nailed it for me. There does not seem to be much thought to the user experience on the whole.