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: Inconsistency in meaning of "user options" Date: Mon, 12 Dec 2005 14:23:35 -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 1134429512 12710 80.91.229.2 (12 Dec 2005 23:18:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 12 Dec 2005 23:18:32 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 13 00:18:31 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Elwv3-0004rv-LR for ged-emacs-devel@m.gmane.org; Tue, 13 Dec 2005 00:17:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElwvZ-000292-6p for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2005 18:17:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Elw5o-00048R-Vs for emacs-devel@gnu.org; Mon, 12 Dec 2005 17:24:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Elw5m-000482-M6 for emacs-devel@gnu.org; Mon, 12 Dec 2005 17:24:24 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Elw5l-00047h-7c for emacs-devel@gnu.org; Mon, 12 Dec 2005 17:24:22 -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 1Elw7X-0002Pz-Sc for emacs-devel@gnu.org; Mon, 12 Dec 2005 17:26:12 -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 jBCMNbQF021650 for ; Mon, 12 Dec 2005 15:23:37 -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 jBCMNbM0005166 for ; Mon, 12 Dec 2005 15:23:37 -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 jBCMNao2005160 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 12 Dec 2005 15:23:37 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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:47574 Archived-At: Sometimes we use the term "user options" to mean "customizable variable" or "variable meant for the user to set". But sometimes we use it to mean "any settings you can customize", which includes faces as well. I think we should make this consistent. There is more than one way to do it; all of them will take work. The question is, which one is better? We discussed this a while back, but I agree that it would be good to come to a conclusion. Are you proposing that we discuss and decide this _now_, and make the necessary changes before the 22.1 release? If so, here are a few thoughts: - "Option" means choice. All user settings involve choice, so they are all user options in this general sense. Another term for this is "user setting" or simply "setting". "Option" is usually better than setting to indicate something that can be changed at runtime. - If we chose to reserve "user option" for user-settable variables (those that have `*' as doc-string first char or are defined with defcustom), then we would have the least amount of work to do. This is because that is what "user option" has meant, historically (with perhaps a few more recent exceptions). In that case, since all faces are customizable, the terminology would be: 1) "user option or face" (all), 2) "customizable user option" (defcustom), 3) "user option" (which includes #2), and 4) "face". - If we decide to start from scratch, then the terms might be 1) "user option" (all), 2) "customizable user variable", 3) "user variable" (which includes #2), and 4) "face". - One problem with the previous choice is that it might not always be clear that "user option" includes faces, especially given our legacy terminology. If we want to be sure people understand that faces are included, we could say "user variable or face". In that case, the only difference between the two would be "option" vs "variable". - There is also the need to refer to non-user variables (all faces are user-settable). "Internal variable" is one possibility, but some such variables are not so internal. I would prefer "non-user variable" for this. - When there is a need to distinguish customizable from non-customizable user variables (or options), those terms are sufficient: "customizable" vs "non-customizable". On another subject, I think it's unfortunate that the terms "customize" and "customizable" have been appropriated for a particular kind of customization (using Custom buffers) - especially in an editor (++) that is all about customization (not Customization). It makes communicating about customization much more complex and confusing. It would be a lot better if Customize were called Foobar or Whatever. If we rework Customize substantially for Emacs 23 (which I hope we do), how about renaming Customize something else? Of course, if we intend to do that, we should not decide now upon terms like "customizable" (whateverable?). Nested cans of worm-eating worms...