RE: Settings

[Drew Adams <drew.adams@oracle.com>]

> Reading some bug reports about problems with saving Customize settings...

For example?  What kinds of problems saving
Customize settings?

But you go on to talk about non-Customize
settings.  What kinds of problems can you
report about saving those?

Just what's the problem you're trying to solve?

> Emacs should have one way to save settings.

Why only one?  What's the problem?

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

Are you referring to the use of symbol property
lists?  Or just to the fact that such info is
being saved in the init file?  Or are you
referring only to the use of property `disabled'
to control command disabling?

(Property lists are about as old as Lisp, but
there's nothing outmoded or "older" about them.)

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

Similarly, is this about Customize settings or
the fact of saving them in the init file?
 
> 3) Ad-hoc methods for saving key/values in different files
> (~/url/cookies, ~/.emacs.d/network-security.data)
> 
> I think Emacs can do better.

"Ad hoc" and "better' makes it sound like there
is no reason for saving different things in
different files.

The devil's in the details, for all such
considerations.  It can make sense for a given
function to save some info in a specific file
(e.g. chosen by the user).  Depends on the info
and its use.

And it can make sense for some info to be
handled by Customize, as options and faces, and
so saved in the single file that's handled by
Customize.

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

On that, I agree 100%.  I've long advocated
that users use `custom-file' and not let
Customize fiddle with their init file.

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

Define "Emacs", here.

If library synonyms.el has user options for a
cache file and a thesaurus file, then that
library - not "Emacs" - should be responsible
for the functions that update/save such info.

Why would "Emacs" have any need to know about
or include such files in any listing, which
arguably "Emacs" (by way of that library)
saved on the user's behalf?

Likewise, a bookmark library is responsible
for a user's bookmarks file(s).  That's how
it should be.

A user can easily transport just her bookmarks,
or whatever.  Why would we want to save
everything that a user might want to persist
in the same giant file/database?

Customize already lets a user "list" options
and their values, and it does so on a library
basis.

Customize also allows ad hoc (yes) tags, called
"groups" for categorizing its options and faces.
And you can "list" the entries for any group.

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

Again, this should be up to (the user and) the
facility that's managing the persistent thingy:
Customize or a library.  And only if it (its
author) thinks that's helpful/appropriate for
that thingy.

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

No one-size-fits-all solution looking for a
problem to solve, please.

The following should be decided based on the
particular thingy and its purpose:

* Whether and when and where to save it
* Whether and when and where to restore it

And who better knows those conditions than the
relevant library (together with the user)?

Even when to load `custom-file' is problematic.
Ultimately only the user knows what's right
for that.

> if you start, say, Emacs 28, and it converts
> your old-timey settings into new-style settings,

I'll try to be sure to make sure that never
happens. ;-)

Doesn't sound great so far, to me.  Sounds
like a one-size-fits-all solution in search
of a copasetic problem.

But if you report about specific problems
you're looking to solve then perhaps things
will be clearer.

Before inventing a high-level solution, can
we please see some specific problems that
you think call for such a solution?