Let's build a comprehensive list of design considerations when making an Emacs configuration.

Howdy! I like configuring Emacs, and I like comprehensive lists. I thought it might be handy for newcomers and greybeards alike if there were a comprehensive list of things to consider when creating an Emacs configuration. I'll keep the list updated as people comment with their suggestions. Here is the current list: - Made *for me* or made for others too? - Should I use `early-init.el`? - Modular config, or everything in `init.el`? - `straight.el` & `use-package` or no? - Keybinds spread throughout the config or contained in a keybinds section?

That doesn't sound all that useful for beginners IMHO. A few sensible defaults are enough to get started, then learn as you need to. Otherwise it's information overload and you come away with the idea that the cognitive burden of using emacs is too high.

The bullet point with "straight.el and use-package or no" is weirdly phrased. I can almost guarantee you that all configurations with straight are built around use-package, but most use-package users are not at all reliant on straight. They're different kinds of things with related functionality. Also, having (at least) _something_ in the early-init.el is more a result of other decisions such as package manager. Also also, using use-package is objectively better than not using use-package. (there are packages like setup.el and leaf which do the same thing - perhaps this is a better choice to distinguish?) --- This post reads like someone who is in the habit of making a new emacs configuration every week and never touching any of them after. This seems like a poor life to live - constantly demolishing your house and re-erecting it halfway, as if it were built on sand. Distro-hopping but you make all the distros yourself. At that point why not just use completely vanilla emacs? Or GNU nano? Why turn the computer on? Why live? --- I guess I'm just wondering, what's a design consideration and why would one start with it?

I wouldn't consider it "starting over every week", but I do find enjoyment out of making drastic changes to the config just so learn and see if stuff works better. Lots of people are the same, and there's packages like Chemacs2 to support that style of config development. There's also configuration *projects*, like Spacemacs or Doom Emacs or even just some random person's ultra-specific config, that require some planning. Not everyone likes to evolve one single config over their entire life. Some do and that's fine. And in a way I still have a lot of the same config, just in new places and structures. By "design considerations" I mean more of the meta type stuff, how to organize the project and the major choices one can make about the overall layout of the configuration. "Modular or single-file" is a good example, IMO. Do you put everything in one file, or split it off into more-specific modular files? Another example is do you add keybinds for things all throughout the config, or do you keep all keybinds in a dedicated section, or some mixture? I think having at least an idea of all these things is helpful. Those are good points about straight/use-package and early-init. I'm a novice at this and I was just trying to get the conversation going.

Yeah maybe not complete beginners, but I think of myself as a beginner and I'm at a point where this would be helpful. All this really needs is a "hey you don't actually have to worry about any of this if you don't want to" disclaimer. Having the list is inherently useful compared to not having it, in my opinion.

Yeah, I'm probably splitting hairs. I can certainly see the benefit for people who've been using it for a while and want to know what else is possible. There's a great Haskell resource called What I Wish I Knew When Learning Haskell -- it's too much information for a beginner because they would never have experienced the need for the libs and techniques in it, but very useful once you know the language and have hit some pain points.

[deleted]

I don't agree with that a use-package is essential, as this is only a macro wrapping built-in functionality, although cleverly crafted together. And I don't agree that using early-init has a meaning more or less only for the package manager: https://github.com/igorepst/dotfiles-reboot/blob/master/packages/emacs/config/emacs/early-init.el

I like the idea. One addition could be: What completion framework do I use, Ido/Fido, Ivy, Vertico or Helm?

Just finished my own config, until last week I had use doom for about 2 years, because I found doom take more time to boot emacs with pgtk, so I decided to build my own. It was easier than I thought. Here is my exp: + config just for myself, linux+emacs 29 especially + use early-init.el to disable gc can reduce boot time from 4.9s to 2.3s + modular config is more easy to debug(I came across a org line spacing problem, by comment modular individually I found it was due to modus theme config...) + melpa is enough for me, so use-package is good enough (since 29, it's built-in) + I'd like to keep a single `keymap.el`, missing function won't be a serious problem, so I can put `keymap.el` before the other modular, it's quite convenient when you have to comment some modular to debug

Something that may be missing here is: Will this be a literate config, using org-babel-tangle or not?

Also, whether I want to maintain the same config for different OS. In my case MacOS and Linux.

I'm planning a rebuild for this now. I have to use Windows at my current job and want to go all in on org mode for my productivity. So now I gotta figure out how to make one config that loads on both and syncthing for org files and hopefully org-roam

Hey, I used doom for 2 years until last week too. I’m glad that I switched to my own config.

* Made for 5 people and counting. Will likely turn it into a distribution. * Nope. Not at all necessary. * Modular. Don't go with `org` it just adds extra steps for stuff to break. * `use-package` is very much part of `emacs` now. So go with that. * Both. Things that configure the basic emacs, should be in a `keybinds.el`. But some package-specific keybinds (particularly added to a mode-map), should be added to `:bind` with `use-package` so you don't have any dangling functions. * My own theme, using a sparse grey pallete, using fonts to indicate different entities and different sizes of text.

>use-package is very much part of emacs now. So go with that. Really? Since when?

Actually since yesterday. It's in the main branch, but it will be a **long while** before it ships into emacs in the repos. I run `30.0.50.163776-1`, and it's there. But I literally built it yesterday.

Nice

Q: Made for me or made for others too? A: Focus on personal configuration right now. Q: Should I use early-init.el? A: sure. it's important for startup optimization. Q: Modular config, or everything in init.el? A: modular config Q: straight.el & use-package or no? A: I suggest use-package because many people are using it. It's Ok if you prefer builtin `package.el`. When your are more experienced, you can use `straight.el`. Q: Keybinds spread throughout the config or contained in a keybinds section? A: does not matter You could start from some Emacs distribution (spacemacs, doomemacs, prelude, ...?). They have right answers for most questions (like Q2 and Q3).

Do you have any additional considerations you'd add to the list?

Since there is so much flexibility in emacs (insanely, so), I think more a highly opinionated, well-documented in comments (or with literate org mode), possibly with mentions of alternatives set of init files would be better. I know I've certainly learned a lot from other peoples' (and am ashamed to admit mine are not in my GH repo because they're such a mess), but I imagine (much like the popularity of Doom emacs etc) a nice set of well explained inits my go a long way for beginners. (for example, I use my emacs less for coding and much more for note-taking, org-roam, and org-mode task management... I imagine that /might/ be of interest to some people vs some of the setups I've seen.).

The Emacs git repository has no such branch called "main". And use-package was merged to Emacs 29 (which was then merged to the *master* branch).

yeah,and doom emacs is a good start, I copied a lot of keybindings and functions like file and buffer operations, almost same experience except much lighter and faster. Doom used to be a magical black box to me, Now I know exactly what's going on inside.

Steve Purcell's [emacs.d](https://github.com/purcell/emacs.d) satisfies this checklist. It's not as feature packed as Doom, so beginners should have a look at. Another is Kaushal Modi's [.emacs.d](https://github.com/kaushalmodi/.emacs.d).

This my [config](https://github.com/Crandel/home/tree/master/.config/emacs). It`s modular, with early-init.el and based on use-package

It’s the main branch because it’s the main. It can be called other things, but it is **the** main.

Howdy, OP here. I'm grateful for everyone's feedback, but I'm afraid I must have misphrased my question. I was looking for a broad list of things to consider *about* an emacs configuration design, not necessarily looking for answers to the example questions I listed. I would also like to say that I didn't realize I can't edit the text on this post, so my claims of keeping it updated were dirty lies. I am sorry.

Not exactly. During release period, there's no one main branch. Which patch goes where is decided on a patch-by-patch basis.

Well, yes technically. I have limited experience, because I contributed mainly to the `nativecomp`, and that wasn't exactly doing things in the `emacs` way.

Learn Lisp and read distribution's code.

I see more and more configurations where people replace use-package with a custom macro. Examples - Prot and Crafted Emacs. Following that I saw somewhere here a with-package macro, which is like 5 lines long, that does require package and executes body if successful, in the body you put all the configuration for this package. I might return to use-package once Emacs 29 is released, but so far pretty happy with with-package.

I think my question is going misunderstood by basically everyone so it's safe to assume I've asked the wrong question here. I'm not asking for suggestions for my own configuration, I'm asking for things to consider when anyone is planning a configuration project. The questions in my post were examples, not questions.

* Should it be able to bootstrap itself when installed afresh? * Should it work on different environments platforms (e.g. flexible enough to DTRT on OSX, Linux, Windows) without modification? * Should I use a literate/org style, or files with comments? * Should I be happy blindly copying lumps of code I don't understand, or am I going to adopt a discipline of only adding stuff that I understand and code myself? * What is my approach to keybindings? Am I going the Evil route to adopt Vim style keybindings? Am I going to make extensive use of Hydras? How do I configure keymaps across my modules of configuration? * What is my approach to theming? Am I going to switch theme often, and need to toggle, or am i set and forget on theming? Similarly with fonts. * What languages do I need to have support for in place to do my daily work? * What LSP package shall I use - lsp-mode or eglot? * What completion framework am I basing my config on - e.g. Helm, or Ivy/Counsel/Swiper, or Vertico/Consult/Embark

* What should goin in an early-init.el vs what should go in the general config?

Thank you for the feedback, these are some good suggestions!

No worries. I think your question is a great one, as I think it can help us as a community refine approaches to making emacs configuration more approachable. I've been using emacs for 2 decades and still find the topic overwhelming :)

This is a super educational set of files, thank you for sharing. I am curious - you have a lot more stuff set in early-init.el than I've seen in other configs. What was the thinking behind putting that stuff in there, rather than init.el?

I put just needed staff, like all helper files in `~/.cache` dir. Want to keep my `~/.config/emacs` dir clear.

> Vertico This one? https://github.com/minad/vertico

Yes. But OP has given up on the plan of setting up a list of design considerations, regrettably, because too many redditors misunderstood him and just posted what their own setup is.