From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Persistence of variables Date: Sun, 25 Mar 2018 11:57:38 -0700 (PDT) Message-ID: References: <87a7v20xlf.fsf@mbork.pl> <83a7v1lxxz.fsf@gnu.org> <87605p28ma.fsf@mbork.pl> <874ll94uvs.fsf@ericabrahamsen.net> <77e3430c-8533-4962-92fa-3b87e2226563@default> <20180321151926.GF12393@tuxteam.de> <87sh8txefj.fsf@fastmail.fm> <87efk813h9.fsf@mbork.pl> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522004189 3255 195.159.176.226 (25 Mar 2018 18:56:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Mar 2018 18:56:29 +0000 (UTC) Cc: Eric Abrahamsen , help-gnu-emacs@gnu.org To: Marcin Borkowski , Joost Kremers Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Mar 25 20:56:24 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0Aoa-0000ke-9v for geh-help-gnu-emacs@m.gmane.org; Sun, 25 Mar 2018 20:56:24 +0200 Original-Received: from localhost ([::1]:52266 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0Aqd-0000AL-Ok for geh-help-gnu-emacs@m.gmane.org; Sun, 25 Mar 2018 14:58:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0Aq6-00009q-E2 for help-gnu-emacs@gnu.org; Sun, 25 Mar 2018 14:57:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0Aq3-000872-87 for help-gnu-emacs@gnu.org; Sun, 25 Mar 2018 14:57:58 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:43626) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f0Aq2-00086e-Vu for help-gnu-emacs@gnu.org; Sun, 25 Mar 2018 14:57:55 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2PIvfGt192306; Sun, 25 Mar 2018 18:57:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=c7CSjEgZp/ydyNrxD3K5GYxl1Ea2ruw/D8apTbhRpiQ=; b=PB7aH00BHhAYjdbM25mBweJh7AmazExFyrX3K8hjD+8xwJhuZ7Cf497PM8eDF1Uj6N3z gFoZwCPO+Zkolr/EWmog9Br2S/MyWf4nDnqolEGhz+d4hSCycczBDqyGSB5FWizeteGi +i8SdjSjxRKLUsoPqVt1Mn/Vr0oQp4nD9eW+hJ/X4YuuQ5/fE5oANwykSTyIs7PvpeTm 311VNoxtjUdnJQa6xoaKSGubCoSwOFRQZvT5AZnCABlZsiWdanO3lMUCrSktqvGMyNgM iTHwzIqWNZkGEd9/j5v0mDXMIk0fjdQc4YpJH6syUc3XG5iDfppKhN/F/MyWOcgC2Htd wA== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2gxh9t00ch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 25 Mar 2018 18:57:41 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2PIveFF031279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 25 Mar 2018 18:57:40 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2PIvd4Q010514; Sun, 25 Mar 2018 18:57:39 GMT In-Reply-To: <87efk813h9.fsf@mbork.pl> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4666.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8843 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803250220 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:116279 Archived-At: > >>> If you only want to save one variable, just use an option. > >> Of course! > >> What Drew said. The whole thing was in front of us all, we > >> just had to squint the right way. > > > > Well, that depends on the variable. Options (i.e., those defined with > > defcustom) are really meant for user customisation: meant to be set > > explicitly by the user, and meant to be forgotten once set. Yes - although it is not necessarily meant to be forgotten once set. It is sometimes useful for a user to change an option during the same session, sometimes even multiple times. And it can be useful for a user to have a command that changes some option. The rule that code should not trample on user options does not apply to a command that a user invokes explicitly, voluntarily, to make such a change. > > If you want to save a variable that changes regularly and > > that the user doesn't set explicitly, then a user option is > > a bad fit. Yes (although "changes regularly" is not relevant here, IMO). In that case, the persistence is not to provide a user with a persistent cache as much as it is to provide the code with a persistent cache. But is it really the case that the persistence is intended across Emacs sessions for all users? If not, it is, in effect, something personal for the user, regardless of how "regular" the updating might be, and regardless of which file the value is persisted in. > > IMHO the best > > way to deal with that is indeed to use a separate file and to provide > > a user option to set the file path & name. That way, users can decide > > for themselves if they want to keep the file under version control, > > sync it across machines, or not. If the user specifies the file then this is, in effect, user-specific. Whether you make the variable itself a user option, or you put its value in a file whose name is a user option, does not change the fact that the variable value is essentially user-specific. All you're talking about in that case is which file to save the value in: (1) `custom-file' or init file versus (2) some other file. > And this is exactly my use-case: a variable whose value will be > periodically changed. When and how often a variable gets changed doesn't enter into it. What's important wrt user options is whether the variable is user-specific. > And I don't like the hassle of having an option > to a separate file with just this one variable... Of course, if the > only user beside me won't like Emacs messing around with his init.el, > I'll do it that way. If you don't want to save the value in your init file or your `custom-file', and you don't want to save it in some other file whose name you have to specify as an option value, then consider using your bookmark file (which you presumably have already). If you want to do that, just create a variable-list bookmark (using Bookmark+) - it persists and restores any number of variables, including just one. "Jumping" to the bookmark restores the saved variable value. Use command `bmkp-set-variable-list-bookmark' to create and update the value. When you save your bookmark list (or when it is saved automatically), the variable is persisted.