From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: persistent, type-aware internal vars Date: Fri, 30 Oct 2009 08:22:27 -0700 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1256916763 21513 80.91.229.12 (30 Oct 2009 15:32:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Oct 2009 15:32:43 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 30 16:32:36 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N3tSn-00036z-Au for ged-emacs-devel@m.gmane.org; Fri, 30 Oct 2009 16:32:29 +0100 Original-Received: from localhost ([127.0.0.1]:36321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3tSm-0007sy-Ln for ged-emacs-devel@m.gmane.org; Fri, 30 Oct 2009 11:32:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3tKC-0000mO-Ql for emacs-devel@gnu.org; Fri, 30 Oct 2009 11:23:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3tK8-0000jf-0G for emacs-devel@gnu.org; Fri, 30 Oct 2009 11:23:36 -0400 Original-Received: from [199.232.76.173] (port=52042 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3tK7-0000jZ-SS for emacs-devel@gnu.org; Fri, 30 Oct 2009 11:23:31 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:50960) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N3tK7-0002jx-Af for emacs-devel@gnu.org; Fri, 30 Oct 2009 11:23:31 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9UFO38w020369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Oct 2009 15:24:04 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9U9XkQi002444 for ; Fri, 30 Oct 2009 15:24:47 GMT Original-Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 20730859011256916148; Fri, 30 Oct 2009 08:22:28 -0700 Original-Received: from dradamslap1 (/24.5.185.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Oct 2009 08:22:28 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpZdMn2hAWr1mzIQ8ikP/KpVeLgBw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4AEB04EE.010A:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116467 Archived-At: `defcustom': persistent, type control (at creation and update) `defvar': not persistent, no type control Proposal: Make persistence and type control available for internal vars also. You could then (optionally) define an internal variable using `:type' and have it persist across sessions. What would be missing for these vars would be the ability of users to customize them using the Customize UI or `set-variable'. They would not be recognized by Emacs as user options. Functions such as `C-h v' would see them as ordinary `defvar' vars (no `customize' link etc.). The idea is to take advantage of the Customize infrastructure that provides (1) persistence in a user's `custom-file' and (2) type control. It is not uncommon for a library to save some state across Emacs sessions. This is done in various ways, from library-specific files to more general treatments such as `savehist', `desktop', and `session'. Each library rolls its own, depending on its needs. Savehist lets users save any variables they want (via `savehist-additional-variables'), but it is not type-aware and is thus fragile wrt the values that can be saved (printable/readable). And `savehist-additional-variables' is a user option, not something to be manipulated by a library. This is not a proposal to replace any existing ways of persisting state. It's just a suggestion to add another: persistence of individual variables in a user's `custom-file' - but for variables that are not intended as user options. The proposal would make it trivial for a library to provide such persistence - no need to explicitly fiddle with writing and reading serialized data. The values would be saved in the user's `custom-file' purposefully: The main use case is to let users restore state. `custom-file' can point anywhere the user wants, depending on the context (platform etc.). One use of this could be for variables that are like options in the sense of being changeable by users, but are only changeable using commands provided by a library, not via the Customize UI. But the main use case I see is for a library to save internal state. I don't have an implementation, and I won't be creating one. Ideally, the `defcustom' machinery would be added to `defvar' for optional use. It might be easier though to just add a keyword `:internal' to `defcustom', and leave `defvar' as it is. It could also be useful to separate the two features, persistence and `:type', so that you could take advantage of, say, `:type' without persisting the value. For that, we could have an additional keyword, `:nosave'. Most of the work to implement this would be in making the rest of Emacs aware of it. The Customize code would need to be aware of it, so that it wouldn't treat these vars as options but it would still perform type-checking and saving. Some other functions, such as the help functions (apropos, describe-variable, etc.), would also need to know not to consider these as options. I don't expect that the implementation would be a big job, but I'm no expert on the Customize code. WDOT?