all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Clément Pit--Claudel" <clement.pit@gmail.com>
To: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <56C60CAD.3060308@gmail.com> (raw)
In-Reply-To: <831t8aufoe.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2016-02-18 18:25 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17  9:27 Option to not automatically customize-save-variable `package-selected-packages' Angelo Graziosi
2016-02-17 23:05 ` John Wiegley
2016-02-18  1:04   ` Angelo Graziosi
2016-02-18  1:43   ` Artur Malabarba
2016-02-18 16:49     ` Eli Zaretskii
2016-02-18 17:28       ` Colin Baxter
2016-02-18 17:35         ` Kaushal Modi
2016-02-18 18:06       ` Artur Malabarba
2016-02-18 18:15         ` Eli Zaretskii
2016-02-18 20:34           ` Joost Kremers
2016-02-18 21:00             ` Eli Zaretskii
2016-02-18 21:49               ` Joost Kremers
2016-02-19  9:31                 ` Eli Zaretskii
2016-02-19  9:47                   ` Angelo Graziosi
2016-02-19 13:04                   ` Artur Malabarba
2016-02-19 15:50                     ` Eli Zaretskii
2016-02-19 18:29                       ` Artur Malabarba
2016-02-19 18:50                         ` Eli Zaretskii
2016-02-19 19:05                           ` Kaushal Modi
2016-02-19 20:34                             ` Eli Zaretskii
2016-02-21 23:56                               ` Joost Kremers
2016-02-22  0:10                                 ` John Wiegley
2016-02-22  3:37                                 ` Eli Zaretskii
2016-02-22 21:00                                   ` Bastian Beischer
2016-02-19  4:18           ` alex
2016-02-19  9:48             ` Eli Zaretskii
2016-02-19 21:15               ` alex
2016-02-20  7:53                 ` Eli Zaretskii
2016-02-18 18:25       ` Clément Pit--Claudel [this message]
2016-02-18 18:54         ` Mechanisms to persist information Eli Zaretskii
2016-02-18 19:22           ` Jonathan Leech-Pepin
2016-02-20  2:17         ` Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages') John Wiegley
2016-02-20  4:44           ` Eric Abrahamsen
2016-02-18 18:45       ` Option to not automatically customize-save-variable `package-selected-packages' John Wiegley
2016-02-19  4:17       ` alex
     [not found]       ` <vYxebPyde_BnqKsA6mXLVX-_dj3rDIchNBYl3O1LxNhGCR7etgi0R4ZR7de5PU1TZXk9R4YsCjNxqkoh5lBR3Q==@protonmail.com>
2016-02-19  9:47         ` Eli Zaretskii
2016-02-19 22:55           ` alex
2016-02-20  8:27             ` Eli Zaretskii
2016-03-05  0:40               ` alex
2016-02-18 16:19   ` raman
2016-02-18 18:55     ` Angelo Graziosi
2016-02-18 19:00       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56C60CAD.3060308@gmail.com \
    --to=clement.pit@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.