From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Incorporating caching into defgroup/defcustom/defvar for Emacs 25 Date: Mon, 2 Feb 2015 10:08:44 +0000 Message-ID: References: <6AD4DF07-EFCD-48F4-AEE6-333F8D27BA87@seanallred.com> <87a90xqfxg.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d5b7cb73232050e1823b2 X-Trace: ger.gmane.org 1422871744 25763 80.91.229.3 (2 Feb 2015 10:09:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2015 10:09:04 +0000 (UTC) Cc: Sean Allred , emacs-devel To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 02 11:09:03 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 1YIDwE-0005oS-6F for ged-emacs-devel@m.gmane.org; Mon, 02 Feb 2015 11:09:02 +0100 Original-Received: from localhost ([::1]:53764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIDwD-0001qW-BG for ged-emacs-devel@m.gmane.org; Mon, 02 Feb 2015 05:09:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47653) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIDvy-0001qR-UL for emacs-devel@gnu.org; Mon, 02 Feb 2015 05:08:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIDvx-0000tI-GI for emacs-devel@gnu.org; Mon, 02 Feb 2015 05:08:46 -0500 Original-Received: from mail-oi0-x22c.google.com ([2607:f8b0:4003:c06::22c]:58449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIDvx-0000tE-8i for emacs-devel@gnu.org; Mon, 02 Feb 2015 05:08:45 -0500 Original-Received: by mail-oi0-f44.google.com with SMTP id a3so43367292oib.3 for ; Mon, 02 Feb 2015 02:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OWkaPCeS/n005D2CWu+2MAYe5a45FntjyC+MJtnsj/Y=; b=gRFkCUA3rzm+OxG6GmVhvqP+MZXIJ9PJV4JZEoFQL1D4r/geSgrH/rJq6AZVpuJzM3 hrv8CaFS+rxMapfXfDZ61VsBX813MH7RfaBqEBKNZVwn4ZLpd3XBE4yz2WSASk4r33RU KzkzSBzR4Fg6LGHTXtVHS0J72wDtokgtxLAg5i9wSaYQdt77ptuL8T3hpX5b5iUrNxZ/ ZYdNAOCBDLhuofN8q5NrDBrau12ePnWAerTs1ey2aDqy6pFqDFCH6Rwqtu+vNjEBnxyj 1cFrozTM6uAOUCM9qxJB8qZf6IYxgVlii2vqIM8LWiEL74ibBZme33UC7qqSCno85dIT W8PQ== X-Received: by 10.202.218.135 with SMTP id r129mr6244708oig.26.1422871724763; Mon, 02 Feb 2015 02:08:44 -0800 (PST) Original-Received: by 10.76.125.1 with HTTP; Mon, 2 Feb 2015 02:08:44 -0800 (PST) In-Reply-To: <87a90xqfxg.fsf@uwakimon.sk.tsukuba.ac.jp> X-Google-Sender-Auth: M2nw6QWU-Qx-a08BFFjRwia-Lj0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c06::22c 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:182242 Archived-At: --001a113d5b7cb73232050e1823b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 Feb 2015 01:07, "Stephen J. Turnbull" wrote: > > Sean Allred writes: > > > Specifically, his point about defcustom is a good one. Such > > variables shouldn=E2=80=99t be cached in the same sense. > > Why not? Custom provides a "reset" functionality if the user *wants* > to reset. It's not clear to me that a user wouldn't want changes to > customizable variables to persist. I wasn't saying defcustoms shouldn't be persistent, I was just saying they already have a great mechanism for that so they don't need to use this caching mechanism that is being suggested for internal variables. Similarly, internal variables can't use the defcustom mechanism (at least, not without modifications) because (1) they'll show up in the customize interface and (2) they'll clutter up the user's init file. > > > stash.el was and is designed as a patch for the lack of =E2=80=9Cinter= nal > > persistent variables=E2=80=9D. The additional keyword(s?) to defgroup = and a > > defvar* macro would suffice. > > What does stash provide that a session manager such as desktop.el > doesn't? That wasn't clear to me from your long email. With stash, a package can specify that a global variable is supposed to be persistent, and this variable will automatically be saved/loaded from disk. I understand desktop.el provides similar functionality, but, IIUC, desktop.el is more of a user interface. By that I mean sessions are only saved/loaded if desktop-mode is enabled, and desktop-mode might just be disabled because the user doesn't want to restore open buffers/files. Some packages need a way to store persistent data regardless of desktop-mode (see abbrevs and bookmarks, for instance), and so far they've all been doing that manually. Stash provides a simple abstraction for a variable that will be persistent accross sessions. You just declare a variable to be persistent (Sean suggested a `defvar*' macro, but I prefer something more specific like `defstash') and its value will be saved to disk during a session and loaded from disk at the start of each session (very similar to what desktop.el does, but without relying on desktop-mode). --001a113d5b7cb73232050e1823b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 2 Feb 2015 01:07, "Stephen J. Turnb= ull" <steph= en@xemacs.org> wrote:
>
> Sean Allred writes:
>
> =C2=A0> Specifically, his point about defcustom is a good one. Such=
> =C2=A0> variables shouldn=E2=80=99t be cached in the same sense. >
> Why not?=C2=A0 Custom provides a "reset" functionality if th= e user *wants*
> to reset.=C2=A0 It's not clear to me that a user wouldn't want= changes to
> customizable variables to persist.

I wasn't saying defcustoms shouldn't be persistent, = I was just saying they already have a great mechanism for that so they don&= #39;t need to use this caching mechanism that is being suggested for intern= al variables.

Similarly, internal variables can't use the defcustom me= chanism (at least, not without modifications) because (1) they'll show = up in the customize interface and (2) they'll clutter up the user's= init file.

>
> =C2=A0> stash.el was and is designed as a patch for the lack of =E2= =80=9Cinternal
> =C2=A0> persistent variables=E2=80=9D. The additional keyword(s?) t= o defgroup and a
> =C2=A0> defvar* macro would suffice.
>
> What does stash provide that a session manager such as desktop.el
> doesn't?=C2=A0 That wasn't clear to me from your long email.

With stash, a package can specify that a global variable is supposed t= o be persistent, and this variable will automatically be saved/loaded from = disk.

I understand desktop.el provides similar functionality, bu= t, IIUC, desktop.el is more of a user interface. By that I mean sessions ar= e only saved/loaded if desktop-mode is enabled, and desktop-mode might just= be disabled because the user doesn't want to restore open buffers/file= s. Some packages need a way to store persistent data regardless of desktop-= mode (see abbrevs and bookmarks, for instance), and so far they've all = been doing that manually.

Stash provides a simple abstraction for a v= ariable that will be persistent accross sessions. You just declare a variab= le to be persistent (Sean suggested a `defvar*' macro, but I prefer som= ething more specific like `defstash') and its value will be saved to di= sk during a session and loaded from disk at the start of each session (very= similar to what desktop.el does, but without relying on desktop-mode).
=

--001a113d5b7cb73232050e1823b2--