[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

persistent, type-aware internal vars

From: Drew Adams
Subject: persistent, type-aware internal vars
Date: Fri, 30 Oct 2009 08:22:27 -0700

`defcustom': persistent, type control (at creation and update)
`defvar': not persistent, no type control

Proposal: Make persistence and type control available for internal vars also.
You could then (optionally) define an internal variable using `:type' and have
it persist across sessions.

What would be missing for these vars would be the ability of users to customize
them using the Customize UI or `set-variable'. They would not be recognized by
Emacs as user options. Functions such as `C-h v' would see them as ordinary
`defvar' vars (no `customize' link etc.).

The idea is to take advantage of the Customize infrastructure that provides (1)
persistence in a user's `custom-file' and (2) type control.

It is not uncommon for a library to save some state across Emacs sessions. This
is done in various ways, from library-specific files to more general treatments
such as `savehist', `desktop', and `session'. Each library rolls its own,
depending on its needs.

Savehist lets users save any variables they want (via
`savehist-additional-variables'), but it is not type-aware and is thus fragile
wrt the values that can be saved (printable/readable). And
`savehist-additional-variables' is a user option, not something to be
manipulated by a library.

This is not a proposal to replace any existing ways of persisting state. It's
just a suggestion to add another: persistence of individual variables in a
user's `custom-file' - but for variables that are not intended as user options.

The proposal would make it trivial for a library to provide such persistence -
no need to explicitly fiddle with writing and reading serialized data.

The values would be saved in the user's `custom-file' purposefully: The main use
case is to let users restore state. `custom-file' can point anywhere the user
wants, depending on the context (platform etc.).

One use of this could be for variables that are like options in the sense of
being changeable by users, but are only changeable using commands provided by a
library, not via the Customize UI. But the main use case I see is for a library
to save internal state.

I don't have an implementation, and I won't be creating one. Ideally, the
`defcustom' machinery would be added to `defvar' for optional use. It might be
easier though to just add a keyword `:internal' to `defcustom', and leave
`defvar' as it is.

It could also be useful to separate the two features, persistence and `:type',
so that you could take advantage of, say, `:type' without persisting the value.
For that, we could have an additional keyword, `:nosave'.

Most of the work to implement this would be in making the rest of Emacs aware of
it. The Customize code would need to be aware of it, so that it wouldn't treat
these vars as options but it would still perform type-checking and saving. Some
other functions, such as the help functions (apropos, describe-variable, etc.),
would also need to know not to consider these as options.

I don't expect that the implementation would be a big job, but I'm no expert on
the Customize code.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]