Settings

[Lars Ingebrigtsen]

Reading some bug reports about problems with saving Customize settings
(for instance, running two Emacs instances and customising different
variables and saving them will overwrite each other; they're not written
to the .emacs file atomically so an error will make the .emacs file
invalid) reminded me of something that was discussed in the NSM context
years ago, but never acted upon, which is:

Emacs should have one way to save settings.

Currently, there way settings are saved are in three classes:

1) Older stuff:

(put 'narrow-to-region 'disabled nil) saved to ~/.emacs (or whatever
the init file is called).

2) Post-Customize stuff saved to ~/.emacs: 

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(load-home-init-file t t)
 ...)

3) Ad-hoc methods for saving key/values in different files
(~/url/cookies, ~/.emacs.d/network-security.data)

I think Emacs can do better.

As a first principle, I think Emacs should not mess, at all, with the
~/.emacs file.  That's for users to put their lovingly hand-crafted
setqs in.

Second of all, Emacs should allow listing, with one command, all
settings that Emacs has saved on your behalf, and that allows you to
remove anything you don't want to have saved.

And finally, Emacs should save some metadata about the setting, like
when it was done and from what Emacs version it was done.

This is where somebody will say "let's use sqlite3!", and sure, a real
database would be nice.  If someone were to come up with a fast,
query-based solution, that'd be great.

We could also just use an append-mostly data-base-log like approach,
which would go something like this:

There's a file ~/.emacs.d/settings, and whenever we want to register a
command as not disabled, or save a Customize setting, or store an NSM
exception, we just append a form to that file.  It could be, like,

[:type variable :variable load-home-init-file :value t :time
"2019-08-15T14:43:37" :version "27.1"]
[:type plist :symbol narrow-to-region :property disabled :value nil :time
"2019-08-15T14:43:37" :version "27.1"]
[:type key/value :realm "NSM" :key 
"sha1:5b77fdefcb11074b38d23d182a7fb414b0d8be24"
:value "sha1:a7:e2:85:c8:59:2a:e9:06:98:ad:86:ee:ff:ea:39:34:04:6f:e0:c6"
:time "2019-08-15T14:43:37" :version "27.1"]

and when Emacs starts up, then it reads the file and the final value
wins.  (We'd have a compacting function to get rid of redundant
entries.)

Of course the syntax should be a whole lot less verbose -- the file
doesn't have to be very human-readable.

There's a compat issue, though -- if you start, say, Emacs 28, and it
converts your old-timey settings into new-style settings, then if you
shift back to Emacs 27, you may not have settings any more.  But the
converter could leave the forms in place in .emacs and add helpful
comments about them not actually being used any more in Emacs 28, so I
don't think that's an insurmountable problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no