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: facemenu-unlisted-faces Date: Sat, 8 Jul 2006 19:32:19 -0700 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 1152412372 26708 80.91.229.2 (9 Jul 2006 02:32:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 9 Jul 2006 02:32:52 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 09 04:32:51 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FzP6F-0004hN-3d for ged-emacs-devel@m.gmane.org; Sun, 09 Jul 2006 04:32:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzP6E-0007OE-H9 for ged-emacs-devel@m.gmane.org; Sat, 08 Jul 2006 22:32:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FzP63-0007Nq-KN for emacs-devel@gnu.org; Sat, 08 Jul 2006 22:32:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FzP62-0007Nc-4n for emacs-devel@gnu.org; Sat, 08 Jul 2006 22:32:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzP61-0007NZ-Tg for emacs-devel@gnu.org; Sat, 08 Jul 2006 22:32:33 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FzP6n-0000ko-FT for emacs-devel@gnu.org; Sat, 08 Jul 2006 22:33:21 -0400 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 k692WWOj006177 for ; Sat, 8 Jul 2006 21:32:32 -0500 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-80-172.vpn.oracle.com [141.144.80.172]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k692WVxT016051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 8 Jul 2006 20:32:31 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:56833 Archived-At: Perhaps we are miscommunicating. AFAIK, faces are customizable, which means that they are designed to be customized. No it doesn't mean that, any more than the existence of a "variable" means its value is meant to be changed, or the existence of a function name means that its function definition is meant to be changed. Almost anything in Emacs can be changed. But most Emacs facilities do NOT try to be bulletproof against all changes that someone might make. It would be counterproductive. So please forget about arguing that "X has to be bulletproof against changing Y merely because Y can be changed." I give up. FWIW - I never argued that anything should be bulletproof or that anything shouldn't be changeable. My argument was that applying a text property (such as boldness) to text is conceptually simpler and closer to what newbies are used to than is applying a face to text. That's all. You argued that face `fixed-pitch' cannot accomodate the model of applying a property/attribute/style, and that the user needs to think in terms of applying a face in this case - that is, the UI needs to treat it as a face, exceptionally. I argued that we could treat fixed-pitchness in the UI the same way we treat boldness, and there is no need for users to monkey with face `fixed-pitch' at this level. It is no different from any other face; all faces would be available in the faces display, and none (including `fixed-pitch') would need to be available in the top-level menu. The discussion about variables vs constants came up because I mentioned that the face name "fixed-pitch" is an exception to the way most faces are named (in terms of their use, not their appearance), and there is nothing *necessarily* fixed-pitch about that face, since it could be changed. Understanding the concept of "face" includes understanding that a face is changeable, and that is not true of text properties.