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 16:02:03 -0800 Message-ID: References: <439E08AC.5000502@student.lu.se> 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 1134432312 20285 80.91.229.2 (13 Dec 2005 00:05:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Dec 2005 00:05:12 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 13 01:05:09 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Elxdh-0006nx-45 for ged-emacs-devel@m.gmane.org; Tue, 13 Dec 2005 01:03:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElxeC-0006Mf-Ri for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2005 19:04:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Elxcy-0006MS-8f for emacs-devel@gnu.org; Mon, 12 Dec 2005 19:02:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Elxcw-0006ME-BC for emacs-devel@gnu.org; Mon, 12 Dec 2005 19:02:43 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Elxcv-0006M9-6z for emacs-devel@gnu.org; Mon, 12 Dec 2005 19:02:41 -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 1Elxei-0000CB-Ro for emacs-devel@gnu.org; Mon, 12 Dec 2005 19:04:33 -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 jBD025Ja016442 for ; Mon, 12 Dec 2005 17:02:05 -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 jBD02590017032 for ; Mon, 12 Dec 2005 17:02:05 -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 jBD024d8017024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 12 Dec 2005 17:02:05 -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: <439E08AC.5000502@student.lu.se> 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:47580 Archived-At: > - "Option" means choice. Why do we then have to distinguish between variables and faces? Because faces didn't exist when the term was coined for Emacs. Does not option comprise both? If it does then I think option is a good term to use here. Yes, that's what I said in the second alternative I proposed ("starting from scratch"). > - If we chose to reserve "user option" for user-settable > variables (those that have `*' as doc-string first char or > are defined with defcustom), Do I misremember, was not those going to be converted to defcustoms, or? Even if that were decided, it would not affect existing external libraries. The terminology we adopt should (also) address the case of non-customizable user variables. They exist; they will continue to exist in the future, unless we neuter `*'. Personally, I see nothing wrong with them, except that their existence adds more confusion to the Customize/customize mix. > 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. That would maybe be good. Perhaps could we use these terms?: 1) user options 2) custom options (to be distinguished from "Custom options" ;-) I guess the meaning here is obvious, but just in case: 1 - those can not be set with Custom, 2 - those can be set with custom. No, the meaning is not obvious, at least in American English. Something that is "custom" (e.g. a "custom motorcycle") is something that _has been_ customized. The term to use for customizable is "customizable", not "custom". It's also not clear to me what you gain by changing "Custom" to "custom", if your meaning of "custom" is "Custom" (can be set with Custom). My point was precisely to find some term that is different from "custom", to avoid confusion.