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: user preferences (was RE: toolbar conventions) Date: Tue, 20 Dec 2005 10:37:05 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1135107657 28048 80.91.229.2 (20 Dec 2005 19:40:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 20 Dec 2005 19:40:57 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 20 20:40:48 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EonK0-0000bk-Op for ged-emacs-devel@m.gmane.org; Tue, 20 Dec 2005 20:38:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EonKv-0006S1-0G for ged-emacs-devel@m.gmane.org; Tue, 20 Dec 2005 14:39:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EomNF-0005D7-6g for emacs-devel@gnu.org; Tue, 20 Dec 2005 13:38:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EomNC-0005B0-Df for emacs-devel@gnu.org; Tue, 20 Dec 2005 13:38:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EomNC-0005Ar-50 for emacs-devel@gnu.org; Tue, 20 Dec 2005 13:38:06 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EomQM-0002vn-4l for emacs-devel@gnu.org; Tue, 20 Dec 2005 13:41:22 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBKIudYC013851 for ; Tue, 20 Dec 2005 12:56:39 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBKIb6r5025268 for ; Tue, 20 Dec 2005 11:37:06 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBKIb6Dp025258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 20 Dec 2005 11:37:06 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:48105 Archived-At: I think "option" and "face" are good terms for what they stand for currently. The discussion of Custom has to mention them both together so much that we need some word for the two together. I'm not going to write "option and face" over and over. I'm going to use a single term, even if it has to be "foobar". 1. "Foobar" is good... ;-) Seriously - if we _must_ decide this now, then how about this: - We keep "option" as a short way to say "user variable", the latter being clearer and preferable in discussions of variables of all kinds. That is, we do not extend "option" to include "face". - We make it clear (this has already been done, IIUC) that "option" (= user variable) includes all variables that are user-variable-p, not just those that are customizable. - We use "preference" for options and faces, stating this clearly somewhere. An alternative is "setting" - we could choose either "preference" or "setting", or we could choose to use them both, interchangeably. At this level of abstraction, the terminology need not be so formal, precisely because we're not making much of a distinction. - We decide to intend to use "preference" in the future, in preference to "customizable" and "customization" in the Customize UI and in discussions of Customize, when referring to modifying anything intended to be modified by a user. (This includes non-customizable user-variable-p variables.) We don't bother to make doc and UI changes along these lines now, but we choose now "preference" as the preferred way to refer to things intended to be changed by users. - As long as there are non-customizable user-variable-p variables, we use "customizable" to mean changeable and savable in the Customize UI. This would be the only place where we would use the common root "custom" to refer to the Customize UI - that is, we would not, in future, use "customize" or "customized" to refer only to the Customize UI. We should, in general, avoid using any "custom"-root words, because of the potential for confusion. (A shame, for a self-advertised extensible and customizable editor, but unavoidable, I think.) Again, we don't bother to make any changes along these lines now, but we agree to this direction for the future. 2. Open question: What to do about non-customizable user-variable-p variables? Should we try to eliminate these - not only in vanilla Emacs, but eliminate also their possibility? That is, should we eliminate `set-variable's sensitivity to `*' in doc strings? It would certainly simplify the terminology. All user variables would then be "customizable". But see also #3, below. 3. As I stated long ago, I would like to see Customize move in the direction of being better integrated with the rest of Emacs. By that, I mean that users could change preferences in ways other than using the Customize UI directly, but Customize would nevertheless recognize (i.e. could be made to recognize) those changes, and would treat them the same as changes made inside Customize. This would, in effect, extend Customize so that some of its functionality could be used outside a Customize buffer. Examples: a. `set-variable' (better called `set-option', IMO) could be used as a quick replacement for `customize-option' to change the value (but not to save, browse, or do other things that you can do in Customize). To understand what I mean, don't think in terms of non-customizable user variables here; think in terms of customizable options. The point is that a command could be used to customize something, without the user ever entering the Customize UI. b. (just an illustration; not intended as a proposal for inclusion) Command `doremi-face-fg' (in my library doremi-frm.el) lets you modify a face's foreground color incrementally (using the arrow keys). You never enter the Customize UI. You can directly manipulate the color easily until you get what you want. The command also tells Customize that the face foreground has been modified, so that Customize thinks the modification was done inside Customize. The user can then save the setting in Customize. There is no inside/outside Customize here: if the user does `M-x customize-customized' after the change, then the face state shows as "you have set this face, but not saved it...", NOT as "changed outside...". Why? Because that reflects just what the user did. You might say, "That's great functionality, but why not just incorporate an incremental face-changer like that into the Customize UI?" The answer is that we might want to do that in some such cases, but certainly not all. The Customize UI is complex enough. It can't be expected to deal with all of the possible ways we might want to let users modify preferences. There might be several different ways that a user would want to change a face foreground; would we want to integrate all of them into the Customize UI? Better that we should let library writers create new interfaces and have those play well with Customize. This approach doesn't take away from Customize; it extends it and makes it more useful, by integrating it better with the rest of Emacs. Customize would be the central place to make all customization changes, and it would notice all changes made outside it. The reason it does not really play that central customization role today is that it does not play well with changes made outside it. We should look for more, and better, ways to let users modify their Emacs experience - we should shoot for ways that involve _direct manipulation_ more, for instance. We should not try to make Customize encompass all such modifications. We should instead make Customize recognize them and play along with them. Luc and others have pointed out that there are many problematic aspects to trying to integrate Customize with changes made outside it. I don't mean to suggest that there are no problems. But we can try to solve the problems (as Luc has already done, to a great degree), and we can try to move a little more in the direction of a Customize that plays well with Emacs. I would prefer that we discuss this after the release. I mention it (again) now, because Richard has decided to decide on the terminology now, and I feel that possible changes to Customize may affect the terminology discussion (and vice versa).