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: RE: toolbar conventions Date: Mon, 19 Dec 2005 19:32:49 -0800 Message-ID: References: <200512200152.jBK1q4Y24900@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1135049671 29709 80.91.229.2 (20 Dec 2005 03:34:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 20 Dec 2005 03:34:31 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 20 04:34:28 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EoYFP-0006fw-IF for ged-emacs-devel@m.gmane.org; Tue, 20 Dec 2005 04:33:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EoYGH-0005hV-Gt for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2005 22:34:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EoYG8-0005hQ-Uv for emacs-devel@gnu.org; Mon, 19 Dec 2005 22:33:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EoYG7-0005hE-8j for emacs-devel@gnu.org; Mon, 19 Dec 2005 22:33:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EoYG7-0005hB-5V for emacs-devel@gnu.org; Mon, 19 Dec 2005 22:33:51 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EoYJA-00009I-Dk for emacs-devel@gnu.org; Mon, 19 Dec 2005 22:37:00 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jBK3WrBc025784 for ; Mon, 19 Dec 2005 20:32:53 -0700 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 jBK3WrjD023212 for ; Mon, 19 Dec 2005 20:32:53 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw4-141-144-97-57.vpn.oracle.com [141.144.97.57]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBK3WqK5023204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 Dec 2005 20:32:53 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200512200152.jBK1q4Y24900@raven.dms.auburn.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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:48076 Archived-At: In January, some people argued for "preference". We could use that. Or perhaps "setting". What do people think of those? Any other suggestions? "setting" would work. I was the one who mentioned those two terms, but I did not (and I don't think anyone else did) really argue that we should adopt them. I simply pointed them out as common terms. _If_ we decided that we needed another, more general term to encompass both options (user variables) and faces, then we might adopt such a term. However, that would just require us to explain one more name, with little gain in clarity. Remember the view-mode "quit" vs "leave" vs "exit" vs... fiasco: if we have multiple, similar terms (e.g. option + preference), we will be constantly explaining. Also, both "setting" and "preference" have a connotation of persistence, because only saved preferences are available in most other apps (where those terms have been used). I think "option" and "face" are good terms for what they stand for currently. "User variable" is clearer than "option", but "option" is clear enough, IMO. ("User option" is redundant, BTW.) This terminology has worked well in the past, and would continue to do so. I see no real need for a term that refers to "option or face" - that expression is clear enough and short enough. It is of course the _value_ of a variable or the _values_ of a face's parameters, not the variable or face, that are truly the settings, preferences, or options, but I think that that is a distinction we need not make. The simple alternative "option or face" is not even _that_ long I agree. It's a good way to refer to such things. and in certain contexts one can even just use option and rely on the fact that it is clear from the context that in this particular case it applies to faces too. We should avoid that. We gain nothing by it, and we lose clarity. If we decide to stick with "option" for a user variable, then we should avoid employing it in a different sense. And to repeat what I said before: We should not change the terminology before this release - we should just make sure that "option" means user variable everywhere (that is, make only corrections, no sea change). We can revisit the terminology after or along with any changes we might decide to make to Customize for the next (23) release. In particular, as has been discussed, we are pretty much in a box now wrt the common term "customize" (and "customization" etc.) - we are forced to restrict its use to apply only to Customize. That's not good, but we have no choice at this point (for this release). If we do end up making substantial changes to Customize in a future release (which I hope), we can then see if we also want to try to revisit the terminology at that point. Then, in the context of Customize, it might make sense to speak of "settings" or "preferences" (in place of "customizations"), since Customize has an implied notion of persistence.