Re: Feature Request: Per-package custom save files?

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Once the custom settings are split out:
> 1. Load on demand

I don't see any need for it.  The time to load a single customization file
should be negligible unless it's *really* large or causes loading other
files (e.g. if some of the customizations enable minor modes).

And doing it "on-demand" might be very difficult.  E.g. you can't delay
"activate global-reveal-mode" to when reveal.el is loaded, since it's the
activation of global-reveal-mode which would cause loading reveal.el.
And it's this loading which takes the time, so delaying the other
reveal-related settings would be pointless since these take
a ridiculously small amount of time.

If we want to speed up startup, there are several things we can do, but
I don't think any of them would be helped by splitting the
customization file.

> 2. Smaller, more manageable custom files.

We can cut the file in chunks, but that doesn't mean it's necessarily
more manageable.

> The reason this bubbled up for me is that in the past few months I've
> had to go back in time to retrieve a custom file from my local git repo
> because the giant custom file got corrupted during an emacs  custom-save
> at some point -- I've not chased down the culprit -- but when that
> happens, you're left with a giant file that is impossible to fix by
> hand.

Can you give details of the difficulties you encountered?
Would they have been different if the customizations were split
among several files, each of them similarly corrupted?
Or would it only be different under the assumption that the corruption
would have affected a single file, thus reducing the amount of corruption?

The customization file should contain 2 parts: the face settings and the
var settings.  Each part should be sorted alphabetically which (due to
the prefix-convention we use for names) should largely group settings
"by package".

So splitting the "one big file" into several smaller files would not
really change any ordering.

> I now regularly git commit my .custom file to a local repo just
> for this reason

I do that as well, tho not for this reason.


        Stefan