Crafted Emacs Update
This will be a bit of a shorter update on the Crafted Emacs project. Nothing changed from last month on the current version, but a lot has changed on the major changes discussed in my last post.
Updates to modules
Crafted Emacs v2 Alpha. That's what I'm calling it. It's very alpha at the moment. I have worked through all of the modules at this point. The first pass was to accomplish several goals:
- Get rid of the
defcustom
variables as much as possible. There are still a handful left to figure out, but most of them are gone. - Split the modules into
packages
andconfig
modules. The former just updates a list of packages to install which the user will need to make happen, the latter is for configuring those packages, assuming they were installed. - Don't make assumptions about the packages installed. I use
featurep
to check if packages are enabled before configuring them. I also make use ofwith-eval-after-load
in several places to control when configuration takes place. I need to be a lot more consistent with this approach, so will need to review this work going forward. - Things controlled by customizable variables are now (mostly) functions to call. The idea, if it was an optional thing, then not calling the function serves the same purpose as setting the customization option to
nil
.
Removed early-init.el and init.el
With our focus changing from being a “starter kit” to being a set of configurations to quickly craft your own configuration, we don't need startup files. Those are provided by the user. That said, there is a little structure that we assume, so I have both of these files as examples and have commented them heavily to illustrate how someone might approach writing their own.
Expectations
There are some expectations, like the custom-file
is loaded first so we can have the package-selected-packages
value initialized before using any of the crafted-*-packages
modules.
We also need to know where the user cloned the crafted-emacs
project, so these two lines are needed very early in the init.el
file, before using any other crafted
modules:
(load "~/crafted-emacs/modules/crafted-emacs-home-config")
(load "~/crafted-emacs/modules/crafted-init-config")
The first defines a variable, then the second is able to use that fact to find the file where it is defined and set the crafted-emacs-home
value to the project-root
of that file. Or the user can just set it manually, either way, that variable needs a value before we do anything with the modules. The crafted-init-config
also takes a moment to update the load-path
so the modules can be found later.
Once all of the appropriate crafted-*-packages
modules are loaded, then the packages listed in the package-selected-packages
need to be installed. I assume use of package.el
so that is just a call to package-install-selected-packages
. I have a crafted-package-config
module with helper functions for this as well. If the user chooses a different package manager, there are a couple of variables which can be set before using the helpers I provide. Otherwise, just iterate over the list and install the packages. For example, this might work (maybe…):
(mapc #'straight-use-package package-selected-packages)
Once the packages are installed, then they need to be configured, which is where the user would then load any of the crafted-*-config
modules needed. So the order might look something like this:
(when (and custom-file (file-exists-p custom-file)) (load custom-file))
(load "~/crafted-emacs/modules/crafted-emacs-home-config")
(load "~/crafted-emacs/modules/crafted-init-config")
(require 'crafted-completion-packages)
;; ...
(package-install-selected-packages)
;; ...
(require 'crafted-completion-config)
Plans of more things to come
There is still much to do:
- Ensure there are copious code comments describing how to use *everything*.
- Conflate several of the modules into more general versions. For example, I'm planning to get rid of the language specific modules (Python and Erlang in this case, although I'll keep this Lisp module because, well Emacs… it's a Lisp Machine) in favor of a more rich
crafted-ide-config
module. Similarly, the LaTeX and PDF modules will be conflated with the editing module. There are others and I'll have to carefully consider how to best move forward with fewer, but richer modules. - Rewrite the README.org file
- Rewrite the info documentation
- Develop more startup file examples and put them all in the
examples
folder and then document them in the info file and possibly in org files to be loaded from README.org. - Document how steps to disconnect from using Crafted Emacs when your configuration grows beyond needing it. Some of that will happen naturally without needing any documentation. Obviously, if the user is rewriting, copying or whatever chunks of Crafted Emacs, eventually there isn't anything left for them to load in their
init.el
file. However, just in case, I'll mention some of the things one should look for when its time to move on from Crafted Emacs.
While I say things are probably not working, I do have a working configuration I'm using to do the development. It still loads pretty fast, but I don't have my full configuration there (yet). Once I get through more of these changes and the dust settles a bit, I'll move to a “beta” level and start looking for help getting across the finish line so it can be “released”. Which in this case really just means renaming a couple branches since this work will likely not merge to master without significant effort. That is still some time in the future.
Tags: #emacs