Doom-emacs: Package manager in its own repo

[mromyers]

I want to open by saying I really like your [insert good term for .emacs distribution thing], and am pretty impressed overall with just how fast loading is.

Unfortunately, there are some simple ui things that make this particular repo not very compatible with the habits and bindings etc that I've built up until now (mostly related to the built-in behavior around Shackle). I was still pretty blown away by the performance however, and noted that your [insert previous good term] managed to load with twice as many packages as my pretty minimal .emacs in about half the time (even with byte-compiling and stuff). So, I tried just deleting everything from doom-emacs except for the package management code in core/, and organized my existing config into various modules, and I ended up with a drop-in replacement for my current config that loads in about half the time.

I think the mixture of the package-management code and module structure for organizing package behavior are really good ways generally to organize one's emacs config, and would make a pretty good [again, that term, emacs distribution thing?]. Something like a bare strip-down of doom-emacs that just provides an equivalent of your (doom! ) macro, and an empty modules/ directory.

That being said, I had to do a bunch of weird hacking around in core/ with the autoloads to remove all the shackles related stuff, so I'm a bit reluctant to provide my thing as some sort of canonical 'minimal doom-emacs package/module manager'. If you were willing to provide something like this, you could probably structure the files in core/ to make separating out the package-management part a little easier.

[hlissner]

I have plans to extract parts of Doom into other repos in time for v2.1, which, at this rate should happen by around new years (2.0.8 will be my last minor release). The first to go will be Doom's package/module management system, which won't have shackle built into it (I plan to give it its own module in :feature), so you'll get your wish yet.

For the time being, you could try disabling shackle with:

;; in modules/private/USER/config.el
(remove-hook 'doom-post-init-hook #'shackle-mode)

It may be a while, but I'll leave this open and post here once it's closer to happening.

[casouri]

I kind of feels the same and I basically modeled after doom-emacs for my config.
https://github.com/casouri/lunarymacs
It is much simpler( really poor compare to the system doom-emacs has) but working. Personally I like your system better than spacemacs. Spacemacs takes ages to start.

[casouri]

And IMO all you need to do is just move your core-xxx files into modules or give an option to disable them. In a other word let users to make decisions. I think core-os, core-project, core-popup, core-keybindings, core-editor can be extracted.

From my own experience I disliked the mapping of ⌘ and option key mapping and the quit prompt.

It make sense for spacemacs to have a lot of default built in because they want to appeal people into emacs and want to be friendly to beginners. But since doom-emacs are tailored for

neckbeards with blue belts or better in command-line-fu, Elisp and git.

Not making decisions in core is probably better. (And this way you don't need to maintain two repos)

[hlissner]

Not making decisions in core is probably better

Doom is moving in that direction. The develop branch has seen more things moved out of Doom core, like core-popup to feature/popup, a few plugins from core-editor into their own modules, and more will follow.

However, I don't intend to extract _all_ of it. For instance, core-os is certain to stay. Many variable settings and modifications in core-ui and core-editor -- which I consider reasonable defaults -- will stay (though many of the plugins therein will be moved out).

or give an option to disable them. In a other word let users to make decisions.

Is there something in particular you'd like to disable? Many of Doom core's customizations can be undone with a line or two of elisp. However, it requires you be familiar with elisp.

It make sense for spacemacs to have a lot of default built in because they want to appeal people into emacs and want to be friendly to beginners.

I think it makes sense for Doom to impose its own reasonable defaults as well. At the very least, Doom will avoid defaults that can't be undone with one or two lines of elisp. If that isn't true for something, let me know. I simply haven't gotten around to it yet.

From my own experience I disliked the mapping of ⌘ and option key mapping and the quit prompt.

These are both defined in my modules (private/default and ui/doom-quit, respectively), not in core, and are easily disabled. I understand keybindings are a very personal thing, so the default keybinding scheme can be completely disabled on develop by omitting the +bindings flag on :private default, or turning off the module entirely.

[casouri]

Cool. That's what am saying, I know core-ui and core-editor have many basic settings. I meant the exactly you have done --- those plugins in core files.

I probably shouldn't say too much since I don't use doom-emacs day to day. But you know...

I think this function in core-ui.el

https://github.com/hlissner/doom-emacs/blob/f35a49dc7eadcd262e3c2cee69dfbbe060047480/core/core-ui.el#L514

still ask you for confirmation when quitting emacs, right?

And for mapping I mean

https://github.com/hlissner/doom-emacs/blob/f35a49dc7eadcd262e3c2cee69dfbbe060047480/core/core-os.el#L21

(Yeah I use ⌘+V for pasting a lot : P)

[fuxialexander]

@casouri In develop branch if you disable doom-quit there will be no prompts.
For the keybinding, ~I think it really depends on individual preference. However, if no binding was set in the core, by default (correct me if I'm wrong) the command key will be set to something like A rather than super or meta, which will make it much harder to use. Anyway we will need to remap the key, it won't cost much with an additional setq in private/config.el.~
Seems ns-*-modifiers are not mapped, so that might be a leftover? @hlissner

[casouri]

That's true. Probably shouldn't go too far on removing default settings.

[rgrinberg]

IMHO, splitting the doom-emacs repository into multiple git repos will have many unintended disadvantages. Some common ones I can think of immediately:

• Users will have to make sure that they're running compatible versions of all the repos.
• Making breaking changes across the entire set of repos will be much more messy (hard to revert) and difficult (require synchronization)
• Users who don't know the internals as much will have to navigate through multiple bug trackers, git histories, etc. just to understand their config system.
• Reporting bugs will now be more involved as you will need to report more than git commit to represent your current config.
• Setting up things like CI will have to be done and maintained more than once.

Yes, you can workaround many of these issues when you put in enough effort. But this time could be better spent elsewhere. Especially since it's probably possible to achieve whatever modularity is requested here here out of a single git repository. See how modular are ivy, swiper, and counsel with their own elpa packages, even though they're all in a single git repository.

This is a bit of a META note: The popularity and the strength of various config frameworks (like spacemacs, doom, prelude) is that they end up centralizing a bunch of code in a single place. Which is in effect undoing all the chaos brought on by having so many elisp packages being developed in a distributed manner. So I do think that this basically goes the spirit of config frameworks.

Just my 2 cents.

[hlissner]

After sitting on this for a year, a lot has changed. Many of Doom's opinions have moved out of its core. Shackle is gone (replaced by the ui/popup module), mac-command-modifier is back to super, and a number of other former core plugins have moved into their own modules, among other things.

That said, I agreed with @rgrinberg a year ago and still do now. The pros of splitting Doom up into separate repos do not outweigh the cons. In which case, I think I will close this thread and consider it resolved, but feel free to follow up here if you have more to add. Even if some of you aren't using Doom anymore, I appreciate the insight!