From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: offer to save customizations on exit? Date: Wed, 12 Jan 2005 09:51:35 -0800 Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1105552576 5917 80.91.229.6 (12 Jan 2005 17:56:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 Jan 2005 17:56:16 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 12 18:56:07 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Comj1-0004GJ-00 for ; Wed, 12 Jan 2005 18:56:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Comud-0004zc-8Y for ged-emacs-devel@m.gmane.org; Wed, 12 Jan 2005 13:08:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Comto-0004ge-2K for emacs-devel@gnu.org; Wed, 12 Jan 2005 13:07:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Comtj-0004eN-ON for emacs-devel@gnu.org; Wed, 12 Jan 2005 13:07:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Comtj-0004cq-8c for emacs-devel@gnu.org; Wed, 12 Jan 2005 13:07:11 -0500 Original-Received: from [141.146.126.231] (helo=agminet04.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Comel-0006UA-O4 for emacs-devel@gnu.org; Wed, 12 Jan 2005 12:51:44 -0500 Original-Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j0CHpcv8014022; Wed, 12 Jan 2005 09:51:38 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j0CHpbeq013995; Wed, 12 Jan 2005 09:51:37 -0800 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j0CHpa70008814; Wed, 12 Jan 2005 10:51:36 -0700 Original-Received: from dradamslap (dhcp-4op11-4op12-west-130-35-178-203.us.oracle.com [130.35.178.203]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j0CHpZIE008806 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 12 Jan 2005 10:51:36 -0700 Original-To: "Per Abrahamsen" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 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: main.gmane.org gmane.emacs.devel:32164 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32164 The analogy breaks down in two important ways: 1) It makes sense to make temporary changes to your editing environment. Making temporary changes to files has no obvious use. 2) Whenever you customize an option, you have to decide if it should be temporary or permanent. The two both require an explicit action, namely activating a button. When you change a buffer you make no such explicit decision. It's a rough analogy, not a homeomorphism ;-). My guess is that for some kinds of customization, users will typically make changes, set them for the current session, and try them out for a while before saving (I know that's what I'll do). They might make several such changes that modify related UI features, for instance. After trying the changes for a while, it would be convenient to save them all or some of them - or not. That possibility is already available, of course, via `customize-customized', but 1) users might not be aware of that, and 2) it's still convenient to be asked on quitting, in case one forgets. I don't want to be asked when I leave if I want to save the current value of case-fold-search or debug-on-error, which are two option I set often. Good point. How about letting users exclude certain options, via a "don't ask" list? There could be such a list available by default. I agree that options like debug-on-error are good candidates for such exclusion (by default). It might also be helpful to be able to exclude entire groups of related options (e.g. via keyword :group). But I think it would be a good idea to remove (or hide by default) the UI for making temporary changes. It would make the UI simpler, and I think the trend is that way: To make options persistent by default. I don't have a lot of experience using Customize, so you might be right. You are certainly right that that is the approach usually taken elsewhere. A priori, my thought is that it would be a hassle to have to re-edit and resave options that I just wanted to try out for a while (to get them back to the way they were before experimenting). I'd rather be able to just quit my session, knowing that I hadn't messed anything up. Also, to get more or less the effect of not having temporary changes, either 1) a user can reply "Yes to All" (one keystroke), or 2) the "don't-ask" list variable could be made to recognize two special values, instead of a list of options: `t', meaning "save all changes, without asking", and `nil', meaning "save no changes, without asking". And it might also be helpful to have an explicit "ask" list, for exceptions to ask about when the "don't-ask" list is `t' or `nil'. Also, I should have mentioned earlier that the proposed "ask-when-quitting" behavior should be a user option (perhaps turned on by default): you should be able to bypass it altogether, if you wish. This could be implemented by having "don't ask" set to `t' (or `nil') and having "ask" set to `nil'. On a subject related to your suggestion to do away with "set for current session", I wonder about the distinction between _editing_ an option value and _setting_ it for the current session. I assume that the state of edited-but-not-yet-set exists because the UI otherwise cannot know when editing is finished - is that right? We might consider making it somehow more obvious that an edited value has not been set - I can imagine users getting bit by this, not noticing the change in label saying that they have edited but not yet set. Finally, I think it would be ideal if _all_ changes to all user options (variables with "*" starting their doc strings) were included in such a scheme by default - have `set-variable' and even `setq' (for user options) add to the customized-options list, at least when they are executed interactively (`M-x', `M-:'). That would help make Customize play better with the rest of Emacs. I'm sure that this opinion will be more controversial, however. (A priori, my thought would be to even remove the "at least when executed interactively", and see what problems might arise if we tried to tie all changes of user options to the customized-options list.) - Drew