on.el - ports of Doom's custom hooks for vanilla Emacs users

It's a pretty small package right now, basically just offering `on-first-input-hook`, `on-first-buffer-hook`, and `on-first-file-hook`. But I plan to flesh it out a little more as I build out my vanilla Emacs config and move away from Doom. Contributions welcome!

> speed up Emacs startup by providing finer-grained control of the timing at which packages are loaded If you aren't using doom you may find it's fast enough already ☺️

I installed Emacs at work and installed four essential packages, and the startup time went from being perfectly fine to being weirdly slow. We're not talking very long, in the grand scheme of things, but from half a second to maybe two? And, granted, I don't restart Emacs a whole lot either. Still, I'd argue it isn't fast enough. If startup times are 4x as long after installing a couple of scripts... yeah.

You probably don't need more than the built-in `after-init-hook`

I've mostly finished writing a package meant to offer a bunch of additional configuration helper utilities that you might also be interested in. Part of the goal is to include anything from Doom that isn't already packaged. There is some overlap between my package and yours, but I've taken an alternative approach. Instead of the indirection to hooks, I've add a more advanced condition system that can be used to run code only once. That said, I think these hooks are very nice from a user perspective, and my condition system doesn't handle the other general doom hooks, particularly `doom-switch-buffer-hook`, `doom-switch-window-hook`, and `doom-switch-frame-hook`. I was going to add these in my package, but I think they fit better in yours. Would you be interested in adding them, and maybe we can recommend using each other's packages as alternatives to doom-only functionality? I'm also interested to know what else you find needs a standalone package from Doom. If it fits with my package, I'll be glad to add it. So far here are the utilities (a lot of them are just extracted from general.el) - Various setq helpers that have setq syntax but use custom setters when necessary - Alternate hook and and advice definers that allow for lists as arguments and run-once or run-once-on-condition functionality - Corresponding use-package keywords (e.g. two hook keywords, one that can automatically generate the hook name from the package name, and another that can automatically generate a mode name to run on some hook from the package name) - The setting, hook, and advice helpers will all eventually integrate with [annalist](https://github.com/noctuid/annalist.el) - Various deferred evaluation utilities (most relevant to Doom) - A utility called `satch-once` that will run code one time once any specified condition is met. The condition can be a hook running, an advised function running, or a package loading. Additionally, there can be checks before and after that must be met to run the code - What the above utility actually allows for is for is a bunch of utilities like "run after gui," "run after tty," "run after first window," "run pre-command or :before after-find-file," etc. - Corresponding use-package keywords (currently :once and :require-when) - Various other small utility functions (like a helper to generate a named function to disable a mode) - I also plan on adding :defer-incrementally and setq-hook This is a more basic example: (defvar satch-after-gui-condition '(:initial-check (lambda () (and (not (daemonp)) (display-graphic-p))) :check (lambda () (display-graphic-p)) :hooks 'server-after-make-frame-hook)) More complicated examples can specify a combination of hooks, packages, and functions to advise, and each individual hook, package, or function to advise can optionally have an additional check that gets passed the arguments for that hook or advised function.

Which packages did you install? If you autoload them instead of immediately `require`-ing them, the impact should be minimal.

If you have made a serious consideration of the benefits of these hooks for users as compared to what emacs provides out of the box — perhaps after you have gained some experience with this package, or maybe before then — I strongly suggest that you put a little time into writing up those considerations and sending them to emacs-devel, so they might be included in future releases. In general, emacs-devel considers adding hooks relatively “easily”, and I know that there have been multiple small efforts made to reach out to Doom, Spacemacs, and the like to ask if there’s anything that core emacs could provide that would help. My understanding in those two cases (Doom and Spacemacs) is that they have added extra hooks and layers to make their own packaging, management, and maintenance easier, which is exactly how emacs-devel thinks it should work. Sometimes, though, the efforts point to a facility that would be better included for everyone; this is why emacs is working to include use-package by default, for example. The main things that stop emacs from including hooks by default, as far as I know, are either proposed hooks that can be easily created from what emacs already provides, or hooks that are too likely to present serious performance problems. Either way, I think your efforts here are valuable, and I hope they can lead to benefit for lots of emacs users. Kudos!

> I was going to add these in my package, but I think they fit better > in yours. Would you be interested in adding them, and maybe we can > recommend using each other's packages as alternatives to doom-only > functionality? Sure! > I'm also interested to know what else you find needs a standalone > package from Doom. `+evil:apply-macro` could use a home outside of Doom, although it would be tiny on its own. There are a lot of niceties I miss from Doom, but it's hard to say which of them should be made into a standalone package. In most cases I think it's probably more appropriate to contribute the configuration or work-arounds in Doom as new options or bugfixes upstream. There are just hundreds of little hooks in Doom that only implement friendlier "defaults" for this or that package. > So far here are the utilities (a lot of them are just extracted from > general.el) I didn't even realize that `general` provided more than keybinding helpers. I've held off on adding `general` to my new config so far because I want to see if `transient` can replace the kind of leader key-based menu that Doom and everyone else are using. Anyway, your list looks pretty nice. I think the most helpful utilities from Doom are `add-hook!`, `setq-hook!`, `add-transient-hook!`, `map!`, and `defadvice!`. If you have equivalents for those (except maybe `map!`), I'd be happy.

> Sure! Great, I may add your package as a dependency for satch.el or at least use it in my config. Right now, I just have Doom's code for these hooks copy/pasted in my config. > +evil:apply-macro could use a home outside of Doom, although it would be tiny on its own. Yeah. Seems like it would make sense in evil directly or in an extra operator package. yack-unindented too. > more appropriate to contribute the configuration or work-arounds in Doom as new options or bugfixes upstream. There are just hundreds of little hooks in Doom that only implement friendlier "defaults" for this or that package. Agreed. I think better defaults/configuration are what starter kits/distributions are for, but the bugfixes should ideally be upstreamed. I'm not completely familiar with Doom, but for me the main things that should be separate packages are the use-package/configuration utilities for settings/hooks/advice/deferred evaluation and the template system (if Doom still has its own). Yatemplate seems good for templates. Satch.el will have the configuration utilities including functional equivalents of add-hook!, add-transient-hook!, defadvice!, and setq-hook! (soon), but the syntax is not exactly the same. Same for `map!`. I don't like the syntax, so I won't add it directly, but it is a relatively small dsl on top of general.el, so someone else can extract it to a package if they want. I will make some of the improvements to general's syntax in the next version based on what people liked about map! though. > I didn't even realize that general provided more than keybinding helpers. Most people don't, which is one of the reasons I'm making them a separate package. There's too much extra stuff in general.el. > I've held off on adding general to my new config so far because I want to see if transient can replace the kind of leader key-based menu that Doom and everyone else are using. Well general.el is potentially useful for any type of keybinding, not just prefix keybindings. I like transient for less used keybindings or anything like magit where there is switch/flag toggling. Otherwise, I don't need the visualization, but I think transient the best looking and most flexible option for prefix keys. The simplest is probable hercules, which just uses which-key.