Comments (7)
Pull request #53 is a start, now we just need to fill it with some examples.
from crafted-emacs.
Some addition thoughts here...
Example configuration(s) should show use of each custom variable and proper use of the features in each module. We should take special care in looking at the order in which things are required in the examples. While the desire is to have each module independent, there are some dependencies (maybe need another issue to tackle that).
I would suggest example-config.el contain the most basic configuration and the README.org (or supplemental documentation) contain variations and more targeted configuration examples. This will give users a basic starting point and documentation from which they can pick and choose what to include in their own configuration. This would also help with the "Helps you learn Emacs Lisp" goal of the project by not simply providing a mostly-complete example configuration.
from crafted-emacs.
Continuing this line of thought, we might want to organize customize groups by module. So have a defgroup for rational that is a "top level" customization and overrides things in the init.el file, then for each module, have a defgroup rational- and include a group property for both rational and rational- (an example would be abbrev-mode which adds both abbrev
and convenience
groups).
examples:
in init.el
(defgroup rational nil "Rational Emacs Configuration")
in rational-ui.el
(defgroup rational-ui nil "Rational UI Configuration" :group rational)
(defcustom rational-ui-default-font nil "... elided text..." :group rational-ui :group rational)
This also helps to document each module's "interface" along with doc strings in "public" defuns.
Food for thought.
This begins to beg the question if we are simply providing a "rational" configuration or a set of modules to support a configuration. I believe these are two very distinct things.
True, yet not necessarily conflicting or mutually exclusive. Perhaps a bit bigger, from one perspective, than the stated goals though.
We may also want to implement functions in each module to actually turn the functionality on/off, rather than just setting the features/settings when the module is required. There are trade-offs here also.
Yes. I like this idea, an alternative one would be hooks, but that implies this is a "package" of sorts and maybe not what we intend... bigger scope etc (see above).
from crafted-emacs.
I think this topic raises some larger issues also with respect to when and how things are loaded.
Yes, that was why I made it an issue of it's own.
Using custom variables to turn on and off features that is external to vanilla Emacs should probably be a lowest common layer.
I am really learning so much by Rational Emacs.
I imagine most users will simply take the example configuration and add to it.
Yes, I think that most users will at least start with the configuration files and then look into that how to turn on and off things when they +start+ boot Emacs. And I think that is something that is enough to begin with. Changing the configuration after start is probably not something many will do.
Unless we were to add the setting of each custom variable (possibly commented out) in the example file, it will be easy for someone to get unexpected behavior without digging into each of the modules.
Relations between the modules are a problem, which could possible be solved with require
and test for featurep
and check for methods etc. There are several ways to check, and I think it is a learning experience if we could have several ways of configure Rational Emacs (and thus teach how to configure vanilla Emacs).
We may also want to implement functions in each module to actually turn the functionality on/off, rather than just setting the features/settings when the module is required. There are trade-offs here also.
Functions for turning features on and off could be provided, where that is not to hard to provide. And possible not for every feature. At least turn on or off when booting Emacs could be a lowest level too, at least in some way in users configure.el
.
This begins to beg the question if we are simply providing a "rational" configuration or a set of modules to support a configuration. I believe these are two very distinct things.
I see Rational Emacs as an relative easy entrance to easy make configurations, and have some code to look at and lastly to run ones own configuration. Based on Rational Emacs, or not. And yes, I learn a lot, at least. Despite using Emacs since 1985 or something on an Pr1me P750 server (comparable to a VAX 750, which probably are as strange as the Pr1me runinng Primos and Primux :-) )
Continuing this line of thought, we might want to organize customize groups by module. So have a defgroup for rational that is a "top level" customization and overrides things in the init.el file, then for each module
I thought about this too, so I like!
from crafted-emacs.
I think this topic raises some larger issues also with respect to when and how things are loaded.
we should use customize variables with defcustom
I agree with the defcustom
idea, but we will need to ensure that the proper items are triggered when setting these variables. A common practice is to simply set
custom variables instead of using custom-set-variables
. The latter allows additional code to be run when the value is changed, which is likely what we would need to avoid some of the load order issues which could occur.
I imagine most users will simply take the example configuration and add to it. Unless we were to add the setting of each custom variable (possibly commented out) in the example file, it will be easy for someone to get unexpected behavior without digging into each of the modules.
Many things can be easy to turn off later, others are not that straight forward.
We may also want to implement functions in each module to actually turn the functionality on/off, rather than just setting the features/settings when the module is required. There are trade-offs here also.
This begins to beg the question if we are simply providing a "rational" configuration or a set of modules to support a configuration. I believe these are two very distinct things.
from crafted-emacs.
Added some comments to #53, even though it has already been merged... Here is a gist (see comments from #37 ) which might be a useful start to an early-config-example.el
: https://gist.github.com/jeffbowman/7d0e20df9321aaa28468c2a32503d322
from crafted-emacs.
Closing in anticipation of Crafted Emacs V2, and this probably no longer applies since the name changed from Rational Emacs to Crafted Emacs several months ago.
from crafted-emacs.
Related Issues (20)
- [craftedv2beta] Broken configuration guards (Tracking Issue) HOT 4
- [craftedv2beta] Improve documentation for using straight.el HOT 7
- Provide option for easier module loading. HOT 7
- [craftedv2beta] Use `customize-save-variable` vs. `customize-set-variable`? HOT 11
- [craftedv2beta] Question regarding the skeleton for new modules HOT 5
- Discussion: When do our own `defcustom` variables make sense? When are they best avoided? HOT 6
- [craftedv2beta] Evil bindings in crafted-speedbar are duplicate and inconsistent with evil-collection HOT 3
- [craftedv2beta] Standardized way for naming functions HOT 5
- [craftedv2beta] Unused function `crafted-completion/minibuffer-backward-kill` HOT 2
- texinfo tags in doc headings don't seem to be needed HOT 3
- [v2] Emacs 29+ check for executable prevents Treesitter setup HOT 12
- [v2] No easy way to opt out of tree sitter parsers HOT 5
- [v2] Corfu + Eglot have unsuitable performance for medium/large projects HOT 4
- [v2] defgroup crafted-startup not functioning properly
- [v2]package-selected-packages "Combobulate" problem. HOT 3
- Automating regeneration of Info file HOT 13
- Suggestion: Make examples loadable HOT 3
- Symbol's function definition is void: treesit-auto-add-to-auto-mode-alist HOT 3
- `crafted-init-config` automatically finding directory possibly confounded by submodule use HOT 9
- Eglot doesn't automatically load when a relevant mode is visited until explicitly required HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from crafted-emacs.