I am learning to adopt emacs and I am curious about the apparent chaos

I am trying to switch most of my software to "boring tech". That is not an insult it is praise. I am tired of a new IDE coming out often, having to learn it, then something else comes along as the new fad and so on. I want to invest my time better by choosing mature, well proven solutions with great staying power. Emacs has all of that. I am a bit confused that things seem chaotic, at least in parts. I am wondering if this is my trying to chase down the wrong extensions. One I was looking at had been removed from the central repo and moved to a different one and I got confused adding a second repo and gave up. There also seems to be a lot that you have a bit of luck getting to work compiling some C code and other (outside of Emacs) requirements. I am thinking I am chosing new, or not popular packages? That for most things everything I nee is in the standard repo?

Please be more specific

Emacs has a steep learning curve, so don't let yourself get discouraged if things seem chaotic at first. >One I was looking at had been removed from the central repo and moved to a different one and I got confused adding a second repo and gave up. I'd recommend looking into building a reproducible configuration with [straight.el](https://github.com/raxod502/straight.el) and use-package. Especially since stability is your goal. Straight chooses a repo automatically if the package is in elpa, melpa or emacsmirror and if you're unsure or it doesn't work you can specify a github repo easily via a simple recipe format. Unlike package.el (the built-in package manager), all information is contained within your init files, which ensures that your configuration can bootstrap itself without requiring manual reinstallation of previously manually installed packages. It also allows you to freeze package versions to a specific commit that works for you, you can't get anymore "boring" than that. >I am thinking I am chosing new, or not popular packages? Nobody can tell if you don't list what packages you choose for what.

This.

You don't give us much to go on to help you, but here are some thoughts: * Try looking at how others have written their configuration, what packages they use, etc. With a large enough sample size, you should start to see similarities that can guide you to your own configuration. * Try out-of-the-box configuration, examples would be: * [Rational](https://github.com/SystemCrafters/rational-emacs) (I'm one of the maintainers, so happy to help with this one), * [Prelude](https://github.com/bbatsov/prelude) (by the author of Projectile and other nifty Emacs packages), * [Doom](https://github.com/doomemacs/doomemacs) (might have to figure out turning off evil (ie vi style) keybindings), * [Spacemacs](https://www.spacemacs.org/) (makes creative use of the space bar among other things). * Try looking through the Emacs customization UI, it will generate a config with your preferences. It won't help you with which packages to install, but if you have some installed, will help you with configuration - by this I mean it provides an interface to see what options are available, read about their settings, etc without having to write Emacs Lisp code by hand to do the same thing. * Use `M-x list-packages` to get a list of packages and one line summaries for each. You can use `C-s` to search for keywords and then press `return/enter` to view more information about a package to see if it meets your needs. If you can be more specific, though, we can maybe address your concerns more precisely. When it comes to Emacs packages, there are many many many of them, and there is a lot of overlap between packages. As far as "best" package to provide some feature, there isn't really one of those per se. Company, Auto-Complete, Corfu all provide completion frameworks, but which one you choose is largely a matter of preference. Same thing with Helm, Ivy, Consult, and others which overlap in the minibuffer completion space but with different UIs and features. For package management, there is the built-in `package.el` which is my preference, but there others like `straight.el`, `quelpa`, and `borg`. Then there is `use-package` which is a very nice "front-end" to most of those (I'm generalizing and simplifying a bit here), and it's very popular - you'll see a lot of examples with it. So, maybe some of the apparent "chaos" you perceive is more related to the strength of Emacs, you can have it your own way, and everybody does. Hope this helps.

>Unlike package.el (the built-in package manager), all information is contained within your init files, which ensures that your configuration can bootstrap itself without requiring manual reinstallation of previously manually installed packages. Counterpoint... With package.el, you can: * Define everything in your init file, * Not edit your init file at all, if you don't want to, * Install missing packages automatically, * Pin packages to specific versions, and/or * Install packages from a simple, easily searchable interface without leaving Emacs. It won't go to Github and clone packages for you. But if you really need to install something from Github, you can always clone it yourself and use `package-install-file` to install it. It's also built-in, which ought to earn it some points for reducing the chaos of additional stuff to install and configure. In case it's not clear, I like package.el a lot. (I've used straight.el too, and I had no complaints about it. It just wasn't necessary for my purposes.)

> I am a bit confused that things seem chaotic, at least in parts. 1. Start without any external packages. 2. Work through the Emacs manual. ("C-h i m emacs RET") 3. If you like videos, watch [Prot's videos](https://www.youtube.com/playlist?list=PL8Bwba5vnQK14z96Gil86pLMDO2GnOhQ6). There are some other great video bloggers, but Prot starts with core principles and sticks with them even as he goes deeper into the rabbit hole. 4. [Mastering Emacs](https://www.masteringemacs.org/) > There also seems to be a lot that you have a bit of luck getting to work compiling some C code and other (outside of Emacs) requirements. No way to know what you're talking about. Maybe some package with an external dependency, like lsp-mode? (since you're replacing IDEs) > I am thinking I am chosing new, or not popular packages? Possibly. There is also a lot of stuff out there that is old. The closer you stay to the mothership, the less risk there is of getting lost. > That for most things everything I nee is in the standard repo? I mean, it's hard to resist trying out new bells and whistles. But if you stick to Emacs and built-in packages in the beginning, you'll gain a better understanding of what you need that isn't already there, and how to incorporate external packages that give you those features.

>* Define everything in your init file, * Install missing packages automatically, Yes, but it makes it significantly harder. It does not track which packages you have deliberately installed unless you let it spam your init file with autogenerated code which in turn makes putting it under version control more of a hassle. And if you don't (for example by using use-package's :ensure t), it's quite hard to forget explicitly "ensuring" some previously installed package in your configuration unless you constantly nuke the installation and then see if your config still bootstraps correctly and check if everything you want is still there. With straight, what you see is what you get. If it isn't mentioned in your init file or a dependency, it doesn't exist. >* Pin packages to specific versions, and/or Correct me if I'm wrong but I think package.el can only be told to load specific package versions that are already installed. It can not pin and reproduce specific versions or commits after cloning your dotfiles to a new machine and reinstalling all packages. You'd have to manually download and install the desired versions or use something like quelpa to automate it. >* Not edit your init file at all, if you don't want to, * Install packages from a simple, easily searchable interface without leaving Emacs. I understand how this may be nice for initial discoverability, but I don't see how this isn't an anti-feature if you want a reproducible configuration. When I started to get into emacs, the customize interface and list-packages was a terrible point of initial confusion. >It's also built-in, which ought to earn it some points for reducing the chaos of additional stuff to install and configure. I wouldn't call inserting a small snipped to bootstrap straight "chaos". It's arguably less confusing than trying to get package.el behave in the ways described above. >In case it's not clear, I like package.el a lot. (I've used straight.el too, and I had no complaints about it. It just wasn't necessary for my purposes.) If package.el works fine for you, then that's the only reasonable choice. I know most problems with package.el have a solution. It's just when they pile up and you need lots of fixes and helpers anyway to get what you want, that you might as well fully replace it with straight, el-get, borg or whatever fits your use-case better.

Do you know any resources or config examples that goes in details of using package.el that way? Thanks!

> It does not track which packages you have deliberately installed unless you let it spam your init file with autogenerated code which in turn makes putting it under version control more of a hassle. I think this criticism is misplaced. Although it may not use the Customize system in the same way that package.el does, straight.el won't do anything to prevent Customize from saving to your config file. To prevent that, you need to set `custom-file` to a different filename. Then you can either put `(load custom-file)` or, if you don't want to use the Customize interface at all, simply don't load the custom-file. But that's a different matter. You can use package.el without Customize if you like. > Correct me if I'm wrong but I think package.el can only be told to load specific package versions that are already installed. Right, you can pin to a version you've already installed. But it's not going to go to github or another git repo and pull a specific commit. That's true. It doesn't prevent you from doing that manually if you like. If I were maintaining a config framework that a ton of people depended on (e.g. Doom, Spacemacs, etc.), sure, I'd want to make sure the setup was perfectly reproducible, specific commits and all. But since I only update packages when I want to it's not a problem.

Which way, specifically? "C-h i m emacs RET m packages RET 3" will tell you a lot about installing packages with package.el. > Define everything in your init file, You can provide a list of packages to install, and then install any that aren't already installed like this: (customize-set-variable 'package-selected-packages '(which-key avy vundo)) (package-install-selected-packages) > Not edit your init file at all, if you don't want to, > Install packages from a simple, easily searchable interface without leaving Emacs. For this, just do "M-x list-packages", or select "Manage Emacs Packages" from the "Options" menu. > Install missing packages automatically, The "(package-install-selected-packages)" in the code snippet above will do this. If you're relying on package.el to automatically save your list of installed packages, just make sure that function call is placed *after* your `custom-set-variables` block (or the code that loads your separate custom file if you have one). > Pin packages to specific versions, and/or See the `package-load-list` variable for this. I haven't done it myself. But you should be able to use it to control which version of a package you're loading if you already have that version installed. You can also pin a package to a particular *archive* using the `package-pinned-packages` variable. You can even set the archive to nil in order to prevent any future updates of the package.

I meant by replacing use-package with equivalent settings. But I think you already explained a lot. Thank you!

Keep in mind that use-package isn't a replacement for package.el. It's a convenience macro that can optionally call upon package.el (or straight.el) to ensure the packages you're configuring have been installed. Another thing use-package does is set up autoloads when you use its keywords to configure certain things. An autoload tells Emacs to load a package at the time that a certain function, macro, or keymap is called. But it's unusual that that hasn't already been done for you during package installation. In the rare instance that you want a package to be autoloaded from a function call that the package's author didn't designate for autoloading, you can set it up in your config using the `autoload` function. (I only have a few of these in my config. And the only packages I load on startup are packages that get used immediately, like dashboard.el.) Similarly, everything else `use-package` does can be accomplished using built-in callables like `with-eval-after-load`, `add-hook`, `add-to-list`, and `define-key`. (Of course you can read about any of them by doing "C-h f [function/macro-name] RET".) Use-package can make your configuration more succinct and easier to organize. And it's become almost the de facto standard to find package READMEs that give instructions for it. But if you understand basically what it's doing, you can definitely live without it.

30+ years of on-and-off Emacs use and I'm smiling at "the apparent chaos". I mean, yes... but it's *good* chaos.

Attack your issues one at a time. Ask for specific solutions for specific problems and I'm sure this sub will be very happy to help. And soon you will have your mountain conquered.

thank you so much for your advice. I will do my best to honor it.

Got it! Thanks again for the great explanation.