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

[raman@google.com (T.V Raman)]

Like I said -- (1) is not relevant to me -- not sure why you
spent a whole paragraph beating that dead horse;-)

Where my custom file has broken:


when custom settings that are large s-expressions break during
save -- say the partial sexp gets saved, the whole file breaks.
Examples of large customization settings:

1. Newsticker -- list of feeds

2. keybinding lists from various packages.

Anyway as I said, I have a soution that works for  me -- personal
git repo and cron joab that backs up my custom settings. 

Stefan Monnier writes:
 > > 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