>And every emacs user will have their own set of extensions, carefully curated.

You'll find a lot of common extensions amongst power users. If you browse Emacs blog posts often, you'll see the same names popping up. For an overall view, I recommend Sacha Chua's weekly Emacs news:

https://sachachua.com/blog/2019/06/2019-06-03-emacs-news/

And BTW, a number of the extensions listed on this submission (Org mode, calc, dired, etc) come packaged with Emacs - although for Org mode I really would recommend installing a more up to date version.

To keep your init.el sane, I strongly recommend you keep your init file as an org mode file and use org-babel-load-file to load it. My init file is probably 1500 lines long, but it's very well organized as an org mode file.

You provided a “yet another list if extensions” (from literally hundreds of such lists).

Nearly every single one of those extensions needs to be set up, configured or tweaked in a certain way (the ways differ from extension to extension and how to tweak/configure them can often be found only after some rigorous googling).

And so, you end up with an init.el which is 1500 lines long (which is a magnitude more than some of my standalone production code :) ) or more (I’ve seen some huge monstrosities).

So in my case this led to a sort of fatigue in the end, and I gave up.

I would definitely say that if you're looking for an editor where everything just works to your satisfaction with minimal tweaking, then Emacs is not for you.

I do think you have cause and effect mixed up here. I have customized a lot of stuff because I can. With most other editors/IDEs, I'm stuck. Yes, their configs are much shorter, but only because there is very little to configure over there. I switched to Emacs because with every other editor I used, there was something that really annoyed me and I didn't want to live with it.

>So in my case this led to a sort of fatigue in the end, and I gave up.

You were probably trying to do too much too fast. My init.el evolved over a decade. I'm sure I spent a lot less than 1% of my overall time on Emacs tweaking it. Probably not even 0.1%. I did an initial setup, and started using it for real work. Every so many months, I'd read about a new package and decide to try it out.

>You provided a “yet another list if extensions” (from literally hundreds of such lists).

When you say that, I can tell you're not even trying, given how I explained why this is not just another list of extensions.

To give you an analogy, there are hundreds/thousands of lists out there on productivity apps for Android. Yet you're not going to get even hundreds of different apps listed there. There are hundreds of sites listing the best image editing software, yet that doesn't mean you'll find hundreds of image editing programs listed.

And really, if you feel like you're drowning in those lists, then just don't look at them. I don't read Sacha's Emacs news every week. Life gets busy, and I ignore it for months at a time. Every once in a while, when work is slow, I go to it to see if I can learn something new.

Emacs is a platform. Don't view it as "configuring". View it as installing useful apps. When I first installed Linux, it was "Holy cow! The package manager has so much software!" Saying there are too many packages out there for Emacs is like saying there are too many packages out there for Linux.

In that configuration, would your "real" init.el file still exist? Is the org-mode init invoked from the 'real' init.el?

Yes. You execute the org-babel-load-file function in your real init.el, while keeping almost all of your config in that org file.

Mostly this article, in addition to hearing about how good emacs is from various others, I want to try emacs. On that note, what you're saying sounds really useful - my .vimrc file is organized by folds to due to it's size. However, as a ~30min old emacs user, I have no idea how do do what you said. For example, is there a way to 'org-babel-load-file' when I open my init.el? When I try it by pressing M-x org-babel-load-file then typing ~/.emacs.d/init.el, I get a message "Wrong type argument: stringp, nil"

edit: would you mind posting a sample of your init.el file so I can see how you organize it?

This is the line in my .init file:

    (org-babel-load-file "/path/to/config/emacsconfig.org")

Here's a snippet of the org file:

    * Behavior
    ** Make Unique Buffer Names
    
    When two files of the same names are open, make the buffer names nicer.
    
    #+BEGIN_SRC emacs-lisp
      (require 'uniquify)
      (setq uniquify-buffer-name-style 'reverse)
      (setq uniquify-separator "/")
      (setq uniquify-after-kill-buffer-p t)
      (setq uniquify-ignore-buffers-re "^\\*")
    #+END_SRC
    
    
    ** Prevent Shell Prompt from going to the bottom of buffer
    #+BEGIN_SRC emacs-lisp
      ;; Prevent shell prompt from always going to the bottom of the window!
      (remove-hook 'comint-output-filter-functions
                   'comint-postoutput-scroll-to-bottom)
    #+END_SRC

If you think entering #+BEGIN_SRC emacs-lisp is tedious, put the following in your config:

    *** Emacs Template for Source Code Blocks
    
    I just type <se at the beginning of a line and it gives a source block
    of Emacs lisp
    
    #+BEGIN_SRC emacs-lisp
    ;; Make a template for emacs lisp.
    (setq org-structure-template-alist 
          (cons '("se" "#+BEGIN_SRC emacs-lisp \n?\n#+END_SRC\n" "<src
      lang=\"emacs-lisp\">\n?\n</src>") 
         org-structure-template-alist))
    #+END_SRC

As the comment describes, now in any org file, at the beginning of a line, type "<se" and hit TAB, and it will expand it for you.

> To me the serious obstacle that vanilla emacs is not that powerful at all.

There is no such thing as "vanilla" Emacs. Treat the scripts installed out of the box as a suggestion only.

> Everyone ends up with rather huge init.el setups with increasingly bizarre and arcane settings.

That's called customization. Those little warts are small tweaks done over time to tailor the editor to your liking.

The other warts can be removed by using something such as spacemacs. You can install a whole lot of packages nicely configured by adding a single line.

I threw away double digit megabytes of scripts (because I was vendoring everything before ELPA) for Spacemacs and haven't looked back.