Explain the long term vision for Rational Emacs and how it's different from other Emacs distros
vaidyafamily opened this issue · 8 comments
@daviwil I'm curious, what is your long term vision for Rational Emacs? After having played with it some, the general structure of it seems pretty similar to Doom. There are a number of modules Rational provides to the user, which the user can choose to include or exclude. The user then crafts his personal config around those modules. If someone were to ask me to characterize what Rational is, I would describe it something like a less opinionated Doom. Is that sort of the long term vision for this project? What ultimately distinguishes this project from something like Doom (or the other distributions out there).
This is probably something we should include on the README, but the core differences between this distro and Doom or Spacemacs are the following:
- Don't introduce a new configuration system (new macros, "layers", etc) on top of existing Emacs configuration patterns. The user's own configuration should be written as if it was done from scratch
- Provide pre-configured modules that shorten the time it takes to build a nice, working configuration so that the user can focus on building the other parts they need on their own
- Many customizations in modules should be opt-in so that there is no surprising behavior by default
- Don't configure everything under the sun or provide configurations for every possible popular package. A "lightly opinionated, comfortable base configuration" is the goal in my opinion.
In short, this distro is for Emacs users who want a nice baseline for building their own Emacs configuration while writing actual Emacs Lisp code, not some other distro's configuration code. They should also be able to learn configuration tricks and useful settings by reading the source!
I know a lot of this is already possible in other distros, but typically the convenience macros and patterns provided by those distros get prioritized over writing raw Emacs Lisp. In the end it's more about the intent of using such a distro: do you want "batteries included" without doing much work, or do you really want to build your own configuration over time without having to write everything from scratch at first.
A potential path for a Crafted Emacs user is to eventually abandon Crafted Emacs once their own configuration is complete :)
@jeffbowman should feel free to chime in here with his thoughts too!
Hope that helps!
I am not sure I can add much to the thoughts from @daviwil , but I'll highlight things which I think are generally important to me:
- This isn't a turn-key solution. This should help a user build a configuration quickly, but the expectation is their configuration fills in the holes we (maybe deliberately) leave.
- Not everyone agrees, so everything should be easily reversible. A module that gets someone 80%-90% of what they want is still good enough as long as they can turn on/off the part that does or doesn't make sense in their config. Some people like the doom modeline, I personally do not, so I made it easy to turn off. Some people prefer shorter answers (y/n instead of yes/no), so I made that easy to reverse.
- Speed is important, so using hooks and deferred configuration (ie
with-eval-after-loadfor example) should be used appropriately. - Fewer packages, rather than more, and of the packages we choose, those that are closer to vanilla Emacs as possible - ideally doing more with less.
To support these things, I try to keep these things in mind when I'm working on the project:
- Correctness is important. If we want people to be able to learn from what we provide, we need to make an effort to do things as correctly as possible. Using
customize-set-variablefordefcustomvariables, usingsetqor in some casessetq-defaultas appropriate, putting the code in the correct place during initialization (early-config.el vs config.el and then possibly within the correct initialization hook as necessary). - Documentation should be thorough, complete, and easy to find.
As for a long-term vision, I'd love to see this project fulfill the goal of the opening line in the readme... a sensible place to start hacking your own Emacs config. I'd consider this project a success if someone could start from scratch and in an hour or less get at least 70% of their configuration completed, have something that works for most of their day-to-day workflow. Over time, I might consider that 70% number a bit too low, but for where we are now, we should be able to hit at least that in a lot of cases.
As a secondary goal, I'd echo what @daviwil said - this should be a project that you could eventually outgrow as your configuration matures through your own implementation. Hopefully that means you, as the user, have learned enough about Emacs Lisp, Emacs configuration, making decisions on packages you prefer and configuring them to your taste. Eventually, Crafted Emacs becomes more and more transparent to the point you have replaced it with your own. That journey is worth going on!
Fully agree with @jeffbowman!
I wonder if we should digest some of this thinking as an update to the README to flesh out the ideas further. I think as time goes on, things are becoming clearer! I've updated the issue to reflect the need to update the README with more details.
Has the idea ever been discussed to make Crafted Emacs modular enough to be installed via package.el? In the sense of that the modules are distributed via an ELPA, and users get to pick and choose what they want to install? The bootstrap configuration would then just configure package.el and download a meta-package with the base dependencies.
Has the idea ever been discussed to make Crafted Emacs modular enough to be installed via package.el? In the sense of that the modules are distributed via an ELPA, and users get to pick and choose what they want to install? The bootstrap configuration would then just configure package.el and download a meta-package with the base dependencies.
This implies that it has.
Yes and no... There is the concept that a user might craft their own configuration from certain modules provided by Crafted Emacs but not actually use Crafted Emacs itself. Basically, they would provide their own custom early-init.el and init.el and then use some of the modules from this project. While we endorse this idea, there hasn't really been any movement on "packaging" any of the modules. IIRC, @daviwil made passing reference to the idea in the very early days of (then) Rational (now Crafted) Emacs. There is another issue (#251) which might take a step in this direction.
One of the difficulties at the moment is the tight coupling between the modules and the initialization (ie early-init.el and init.el). This is not necessarily a "bad" thing per se, however, decoupling requires configuration of certain path variables which, if the modules were packages, would need further refinement, probably default values and customization options - not the end of the world, nor impossible to accomplish, but will certainly require some thoughtful development.
For the moment, you can nearly achieve the same effect by following some of the instructions left in #251, specifically this comment.
Hope that helps!
Closing in anticipation of Crafted Emacs v2