From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sean Allred Newsgroups: gmane.emacs.devel Subject: Incorporating caching into defgroup/defcustom/defvar for Emacs 25 Date: Sun, 1 Feb 2015 10:46:56 -0600 Message-ID: <6AD4DF07-EFCD-48F4-AEE6-333F8D27BA87@seanallred.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1422809243 23561 80.91.229.3 (1 Feb 2015 16:47:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Feb 2015 16:47:23 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 01 17:47:22 2015 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 1YHxgA-00036n-7W for ged-emacs-devel@m.gmane.org; Sun, 01 Feb 2015 17:47:22 +0100 Original-Received: from localhost ([::1]:51062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHxg9-0003X3-DH for ged-emacs-devel@m.gmane.org; Sun, 01 Feb 2015 11:47:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHxfv-0003W6-Pd for emacs-devel@gnu.org; Sun, 01 Feb 2015 11:47:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YHxfq-00056g-BH for emacs-devel@gnu.org; Sun, 01 Feb 2015 11:47:07 -0500 Original-Received: from sub4.mail.dreamhost.com ([69.163.253.135]:34571 helo=homiemail-a28.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHxfp-000565-Ur for emacs-devel@gnu.org; Sun, 01 Feb 2015 11:47:02 -0500 Original-Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 7DFEA1B405F for ; Sun, 1 Feb 2015 08:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seanallred.com; h=from :content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; s=seanallred.com; bh=WeqFYk92H/H7LDPQQi710iVAB k8=; b=SqgsxZcxJxQ/fNAvThKnfUF405IumlV5BkA1SmmRU+aNU7vCnHEBFhwKb geSJTeCiferZAUOmADMnTalwKabzLsfmhk4aBc8tgxpGLQ5XLETVQyJSy7GnsFx2 kKJhVxLETgi+EbASnYJekbYQhx2XLfK4zMcTmRsTJkJqnLFR8w= Original-Received: from [192.168.1.135] (71-90-77-44.dhcp.ftbg.wi.charter.com [71.90.77.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: code@seanallred.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 41B161B4057 for ; Sun, 1 Feb 2015 08:46:57 -0800 (PST) X-Mailer: Apple Mail (2.2070.6) X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 69.163.253.135 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:182194 Archived-At: Hi all, Since this is a long email (sorry!), an executive summary: many Emacs = applications use data that is persistent from session-to-session. The = mechanism for doing so varies from application-to-application, but there = are a few packages on the ELPAs that promise this, notably cache, = pcache, and the new stash.el (my own creation for sx.el, both on = github). I=E2=80=99ve discovered a lot of overlap in the way I=E2=80=99ve = designed stash.el and the way the defgroup/defcustom system already = works, so I=E2=80=99m curious to see how open you all are about = introducing caching functionality baked into Emacs. defgroup and = defcustom aren=E2=80=99t so difficult, but defvar (being a C function) = introduces concerns that I=E2=80=99ve yet to truly research / = understand. One of the reasons that makes Emacs so awesome (or at least interesting) = is the variety and number of full-blown application written in/for = Emacs. Gnus and Org are prime examples, and *nothing* would be the same = (for me) without Ido. All of these applications use on-disk data to keep = information from session to session. This need is hardly limited to = Emacs internally, too; Artur and I have been at work on sx.el (on = github), another moderately complex Emacs application that uses (and = outright needs) on-disk data. Most veritable applications use on-disk = data, and I can only guess that they all do so with an in-house = mechanic. The use-case is there. There are a few caching libraries on the ELPAs at this time: cache, = pcache, and stash (my own creation for sx.el). In my honest opinion, - `cache=E2=80=99 is too simple. For one, it doesn=E2=80=99t even save = its data! It merely provides a means for cached data to expire - a = necessary utility for full support. - `pcache=E2=80=99 is too complex (for my taste). It=E2=80=99s not = immediately apparent where/how the data is stored. (Disclaimer: I have = absolutely zero experience with eieio, its sole dependency.) As an added = :(, it=E2=80=99s not available on the GNU ELPA. - `stash=E2=80=99 is, I think, a good compromise between the two, though = some filling out has to be done on the featureset. For example, it = currently does not support cache timeouts. SX hasn=E2=80=99t needed it = yet, but I=E2=80=99m certain other applications would. I=E2=80=99m, = uhhh, I=E2=80=99m working on it :) Something I=E2=80=99ve noticed in writing stash.el (and discussing it = with Artur a bit) is that I=E2=80=99m duplicating functionality. To see = this, let me explain (briefly) how stash.el works: - &optional Programmer defines an =E2=80=98application=E2=80=99. This = application implies a subdirectory within the over-arching = `stash-directory=E2=80=99 where data is saved at some programmer-defined = interval. - Programmer defines a `stash=E2=80=99, optionally belonging to an = application, with an associated filename. This filename is where this = `stash=E2=80=99 is saved to disk as interpreted by `prin1-to-string'. (A = `stash=E2=80=99 is just a variable with a few symbol-properties as = metadata.) - ... =46rom this point on, the programmer just sets the variable=E2=80=99s = value normally (with set/setq/etc.). On an idle-timer (set up by = defining the application - there is a =E2=80=99null=E2=80=99 application = set to a minute=E2=80=99s idle time), the entire application is written = to disk. There are a few flaws in this approach (for example, not every variable = has changed from the time it was last saved), but it=E2=80=99s working = out pretty well. The most glaring flaw in this design is the duplication = of the group-variable association already available (or conceptually so) = in the defgroup/defcustom/defvar system. Given its generally = applicability, I think caching in this (or similar) fashion would be a = good addition to the system via keyword arguments to those three macros: (defgroup sx nil "Customization group for the `sx' package." :prefix "sx-" :tag "SX" :group =E2=80=98applications) ; =3D> Would prepare to create a folder called =E2=80=9Csx=E2=80=9D = in `customize-cache-directory=E2=80=99 =20 (defcustom sx-init-hook nil "Hook run when SX initializes. Run after `sx-init--internal-hook'." :group 'sx :type =E2=80=98hook :cache =E2=80=9Cinit-hook.el=E2=80=9D) ; =3D> Would prepare to create a file called =E2=80=9Cinit-hook.el=E2= =80=9D in `customize-cache-directory=E2=80=99/sx =20 (defvar sx-variable :group =E2=80=99sx :cache t :expire 60) ; =3D> same as above, but basename defaults to =E2=80=9Csx-variable=E2= =80=9D set to expire after one minute of inactivity It=E2=80=99s this last that I=E2=80=99m most concerned about: `defvar=E2=80= =99 is defined in the C source code. I haven=E2=80=99t taken the = slightest peek at Emacs=E2=80=99 C sources, but I=E2=80=99d reckon there = wouldn=E2=80=99t be a simple analog from the approach I took in = stash.el. I=E2=80=99m just not sure. Perhaps the functionality can be = moved to a Lisp defvar*. I see a conceptual overlap with Customize=E2=80=99s own managed = `custom-set-variables=E2=80=99 form, but they aren=E2=80=99t quite the = same thing. It=E2=80=99s worth pointing out the similarity, but I=E2=80=99= m not sure what to make of it. I know this is a long email, so many thanks for reading it through. = I=E2=80=99d really like to know interested thoughts on the topic. I=E2=80=99= m perfectly willing and able to implement the functionality (or at least = do most of the legwork) pending the necessary FSF paperwork, but it = would be a non-trivial undertaking in an already busy schedule. = Moreover, I=E2=80=99m sure there are multiple considerations I=E2=80=99ve = missed :) Best, Sean Allred=