Configuring Rational Emacs and what to use example code in `example-config.el` or `example-early-config.el` for.

[ajxn]

A suggestion is that we should use customize variables with defcustom (perhaps in a group "Rational Emacs") where users can turn features on and off to their liking. Then beginners can use Options menu to control Rational Emacs behaviour.

It would also be good to have some example code in those example*-config.el files. There users then later can comment out or remove configurations to turn features on and off. And then code can be comment out for easy configuration.

Many things can be easy to turn off later, others are not that straight forward. Specially when there are no code to show how that can be done. Some features are also good to have on to show how Emacs can work, and users can easy turn them of later. It is also a way of "trick" beginners to tinker and code some Elisp. Especially if we are careful about how we code.

I think this will give flexibility and make it easy to configure for users. Both through Options and "Gui", and through set variables and write some elisp code. And make it easy for users adopt Rational Emacs to their own needs.

[ajxn]

Pull request #53 is a start, now we just need to fill it with some examples.

[jeastman]

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.

[jeffbowman]

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).

[ajxn]

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!

[jeffbowman]

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

[jeastman]

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.

[jeffbowman]

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.