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 22:45:11 -0700 Message-ID: References: <878xn3fkxz.fsf@catnip.gol.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1152423947 21877 80.91.229.2 (9 Jul 2006 05:45:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 9 Jul 2006 05:45:47 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 09 07:45:46 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 1FzS6u-0002dm-S8 for ged-emacs-devel@m.gmane.org; Sun, 09 Jul 2006 07:45:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzS6u-0008JJ-7C for ged-emacs-devel@m.gmane.org; Sun, 09 Jul 2006 01:45:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FzS6i-0008HQ-Ve for emacs-devel@gnu.org; Sun, 09 Jul 2006 01:45:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FzS6h-0008Ep-09 for emacs-devel@gnu.org; Sun, 09 Jul 2006 01:45:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzS6g-0008Ei-UJ for emacs-devel@gnu.org; Sun, 09 Jul 2006 01:45:26 -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 1FzS7U-0002v8-7t for emacs-devel@gnu.org; Sun, 09 Jul 2006 01:46:16 -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 k695jOaD027862 for ; Sun, 9 Jul 2006 00:45:25 -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 k695jN40031224 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 8 Jul 2006 23:45:24 -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: <878xn3fkxz.fsf@catnip.gol.com> 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:56838 Archived-At: > Understanding the concept of "face" includes understanding > that a face is changeable, and that is not true of text properties. You're apparently using some bizarro definition of the term "text property", because the text properties most of us use are indeed changeable. Maybe you're talking about the practice of using face-attribute lists instead of named faces?? Sorry I'm not getting this across. I'll try one more time. It's really not that important, so hit delete if you're tired of this. I can use the number 4 or not use it, but it remains the number 4 - it is not changeable. I can apply the :bold attribute to text or not, but it remains the unchangeable :bold attribute; if applied, it always imposes boldness. That is different from use of a face whose name happens to be `bold', even if the face looks bold. Whether applied to text or not, the `bold' face is not a constant, and its name "bold" doesn't necessarily stand for how it looks. I tried to say that I was not speaking necessarily of Emacs text properties, or face attributes, or font properties, or styles, but of all of those, on the one hand, and faces on the other. And I was not making a difference in terms of implementation but in terms of user (conceptual) model. Consider some text that has a :foreground face attribute with a value of "Red" applied to it as a text property. The value of :foreground that is applied to that particular text can certainly be changed (e.g. to "Green"), and the :foreground attribute can be removed from the text altogether. But the color "Red" can't be changed; it's a constant. It's not just a name associated with the color, whose association can be changed. And the meaning of :foreground cannot be changed; it always means the foreground color, regardless of its value. Likewise, for face attribute :underline: it can be applied to text or removed, but it always means underlining. Likewise :bold always means boldness. On the other hand, a face that happens to be named `underline', and that has, right now, an appearance of underlining, is not such a constant. Applying the attribute :underline will always underline, but applying the face `underline' will not (not necessarily). The definition and appearance of a face named `bold' can change; the definition and appearance of attribute :bold cannot. Users unused to Emacs don't know or care about faces. They can and will eventually use them, and that's good. But they don't _need_ to understand the notion of a face to be able to apply constant "properties"/"styles"/"attributes" (however such things are defined) to text. That's the model to use for the Text Properties menu, with the sole exception of `Face...', where Emacs faces are applied. Let users think simply in terms of applying boldness, underlining, redness, and so on, where each of these properties (again, however it might be implemented) is thought of as as constant. To my mind, we can treat fixed pitchness the same way. Even if "applying" fixed pitchness really means changing the font family, or even if it really means applying a `fixed-pitch' face, or whatever, things should work simply enough that the user need not be aware of that, that s?he can think of applying fixed pitchness the same way s?he thinks of applying underlining. IOW, think of it as a constant property that you are applying to the text. Finally, I don't really care about fixed pitchness. I don't care whether we provide it along with Bold and the others, as if it were a constant property you can paint text with (even if it is not, in terms of implementation), or whether we force users to use face `fixed-pitch' and be aware that they are doing that. I simply meant to point out that what Richard said was not necessarily true: "For 'fixed pitch', I think that can only be considered as a face." Fixed pitch _can_ be treated like any of the other constant "properties", _if we want_. If you prefer to treat it as an exception, as the only face in the menu (aside from face access via `Faces...'), so be it. My only point about it was that we do not _have_ to present fixed pitchness to the user as a face. (Personally, I'd prefer to remove it from the Text Properties menu, and treat it only in the font menu, as a font-family change - which it is.)