[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mechanisms to persist information (Re: Option to not automatically custo
From: |
Clément Pit--Claudel |
Subject: |
Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages') |
Date: |
Thu, 18 Feb 2016 13:25:49 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
On 02/18/2016 11:49 AM, Eli Zaretskii wrote:
> This seems to be a general complaint about package.el using Custom to
> save the data about installed packages. I see no arguments as to why
> it's wrong to use Custom for that. After all, Custom is our standard
> way of saving customizations, so it could be argued that having a
> single mechanism through which to control where they are saved is
> better than inventing a separate mechanism just for package.el.
One thing that I would find convenient as a package developer is a notion of
package-local storage. Right now, if I (as a package developer) want to persist
information between Emacs sessions, I can either:
* Save the customization through Custom
* Create my own file in user-emacs-directory
The first one is unsuitable for persisted information that shouldn't be
presented to the user (for example, if my package collects statistics, I don't
want to change the custom file constantly and add large amounts of data to it).
The second one in not uniform across packages, and forces me to invent my own
storage format (some packages store a lisp form, other store a series of
command that are just executed upon loading the file (viper, history), others
use json or csv-like formats (as was suggested for package.el)).
In both cases, removing a package won't remove the storage that it uses (either
in Custom or in separate files in .emacs.d). This is especially problematic
when trying out packages: I launch a package to try it out, it initializes its
backing store (often with a file, sometimes with an entry in
custom-set-variables), then I remove it (if I don't like it), and yet the
backing store is not removed. Take viper as an example (though viper is bundled
with Emacs right now): launching it and allowing it to persist its settings
creates a file ~/.emacs.d/viper.
It would be nice to have a uniform way to persist package-specific information;
ideally one that would collaborate with package.el, so that removing a package
would remove its stored state. One would need to figure out how to handle
settings persisted through custom as well, but a simple key-value store that
plays well with package.el would be a great start.
Clément.
signature.asc
Description: OpenPGP digital signature
- Re: Option to not automatically customize-save-variable `package-selected-packages', (continued)
- Re: Option to not automatically customize-save-variable `package-selected-packages', Artur Malabarba, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', Eli Zaretskii, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', Artur Malabarba, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', Eli Zaretskii, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', Kaushal Modi, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', Eli Zaretskii, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', alex, 2016/02/18
- Re: Option to not automatically customize-save-variable `package-selected-packages', Eli Zaretskii, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', alex, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', Eli Zaretskii, 2016/02/20
- Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages'),
Clément Pit--Claudel <=
- Re: Mechanisms to persist information, Eli Zaretskii, 2016/02/18
- Re: Mechanisms to persist information, Jonathan Leech-Pepin, 2016/02/18
- Re: Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages'), John Wiegley, 2016/02/19
- Re: Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages'), Eric Abrahamsen, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', John Wiegley, 2016/02/18
- Re: Option to not automatically customize-save-variable `package-selected-packages', alex, 2016/02/18
- Message not available
- Re: Option to not automatically customize-save-variable `package-selected-packages', Eli Zaretskii, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', alex, 2016/02/19
- Re: Option to not automatically customize-save-variable `package-selected-packages', Eli Zaretskii, 2016/02/20
Re: Option to not automatically customize-save-variable `package-selected-packages', raman, 2016/02/18