Re: Contents of one of my workspaces

vin> As Michael has pointed out, I think we've discussed this one vin> to death, and I wouldn't want to see a change in this area. Stephen> The conclusion of the discussion as I recall it was that Stephen> init-before-custom is broken in theory and practice as an API and Stephen> violates POLA as a UI (users expect their customizations to be in Stephen> effect when their init files are executed, as they are when they test Stephen> them interactively). As I recall the discussion people were worried Stephen> about hypothetical breakage in init files if we switched, but all the Stephen> actual examples of breakage were due to init-before-custom (to the Stephen> extent that there are several people habitually using the device in Stephen> Ben's sample.init.el to load custom first), and all the theoretical Stephen> examples of breakage due to the change would be easily fixed without Stephen> hacking in something equivalent to reverting the change. Stephen> I agree that this is a potentially dangerous and surprising change, Stephen> and for that reason it should be done as quickly as possible. I remember differently, mainly that it's possible to get custom-before-init with the current setup (by loading the custom stuff at the top of init.el), but that it's much harder to get the reverse under the reverse setup. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla