From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Mechanisms to persist information Date: Thu, 18 Feb 2016 20:54:48 +0200 Message-ID: <83d1rtu9vr.fsf@gnu.org> References: <56C43D17.7010009@alice.it> <831t8aufoe.fsf@gnu.org> <56C60CAD.3060308@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1455821686 10898 80.91.229.3 (18 Feb 2016 18:54:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Feb 2016 18:54:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?windows-1252?Q?Cl=E9ment?= Pit--Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 18 19:54:42 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aWTir-0001an-6o for ged-emacs-devel@m.gmane.org; Thu, 18 Feb 2016 19:54:41 +0100 Original-Received: from localhost ([::1]:44471 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWTiq-0002hA-P2 for ged-emacs-devel@m.gmane.org; Thu, 18 Feb 2016 13:54:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWTim-0002ge-1U for emacs-devel@gnu.org; Thu, 18 Feb 2016 13:54:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWTii-0005JR-RF for emacs-devel@gnu.org; Thu, 18 Feb 2016 13:54:35 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWTii-0005JM-NK; Thu, 18 Feb 2016 13:54:32 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2010 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aWTii-00010G-23; Thu, 18 Feb 2016 13:54:32 -0500 In-reply-to: <56C60CAD.3060308@gmail.com> (message from =?windows-1252?Q?C?= =?windows-1252?Q?l=E9ment?= Pit--Claudel on Thu, 18 Feb 2016 13:25:49 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:200146 Archived-At: > From: Clément Pit--Claudel > Date: Thu, 18 Feb 2016 13:25:49 -0500 > > One thing that I would find convenient as a package developer is a notion of package-local storage. We will find a lot of missing infrastructure as we begin using package.el more and more. This is just the tip of the iceberg. FWIW, I think we should first design the package system we want to support, and only after that talk about stuff like saving package-specific settings. But I have no illusions that this will be accepted, or that the discussions will indeed be deferred. > * 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)). Personally, I see nothing wrong with each package using its own storage format. We don't require package authors to use the same coding style and the same abstractions, so why should storage be any different? > 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. Removing auxiliary files doesn't require those files to be in the same format, it can be solved by having each package produce a record of those files that the manager can use to delete them.