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: Wed, 5 Jul 2006 09:54:39 -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 1152118533 29973 80.91.229.2 (5 Jul 2006 16:55:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Jul 2006 16:55:33 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 05 18:55:26 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 1FyAee-0003zn-C7 for ged-emacs-devel@m.gmane.org; Wed, 05 Jul 2006 18:55:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FyAed-0006HC-T3 for ged-emacs-devel@m.gmane.org; Wed, 05 Jul 2006 12:55:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FyAeO-0006FW-2c for emacs-devel@gnu.org; Wed, 05 Jul 2006 12:54:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FyAeN-0006F9-5F for emacs-devel@gnu.org; Wed, 05 Jul 2006 12:54:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FyAeM-0006F4-Vq for emacs-devel@gnu.org; Wed, 05 Jul 2006 12:54:55 -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 1FyAeM-0005Hv-RW for emacs-devel@gnu.org; Wed, 05 Jul 2006 12:54:55 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k65Gsqiw004278 for ; Wed, 5 Jul 2006 11:54:52 -0500 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-80-101.vpn.oracle.com [141.144.80.101]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k65Gsobj001592 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Jul 2006 10:54:51 -0600 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.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:56577 Archived-At: It is far more natural to click Bold a second time to turn off boldness for the selection than it is to think of applying the `default' face to it. That is a good idea. However, this is not the same as what you were talking about before. This is an interface question. You were talking about a conceptual quesion, whether to consider it a "face" or a "face attribute". What the user does with an interface reflects the user's mental model of how things work, which includes concepts of the objects s?he manipulates. Emacs users (though perhaps not novices) will have a concept of "face", but that concept is more complex and less usual than the concept of text property (face attibute, text style, font property - whatever). In the latter case, the user thinks in terms of properties that s?he applies to text. In the case of faces, a user must have something more complex in mind: - A face is a variable, whose value can change. Its name, if it describes the appearance, might lie (a face named `blue' might be red). - A face can have multiple properties, some of which users are not used to associating with displayed text. A simple example is background color, as I mentioned - that is not usually (conceptually) associated with the displayed text. The fact that face named "fixed pitch" has a fixed pitch is a happy happenstance. It is not happenstance. You mean that that association (face name and font family) was deliberate, right? It is a happenstance in the sense that the name happens to reflect the appearance - until someone changes that association. If the face name were Foo or Blue, or if the font family of that face were changed to helvetica, then it would not be such a happy happenstance. With a face, you cannot depend on the name to indicate the appearance - the association of name and appearance is, at any given time, a happenstance. Much more importantly, it is a happenstance for the user. The user is interested in the appearance, not in the fact that it is a face. All the user wants to do is make some text be fixed pitch (or green or bold or blinking or metalic or...). You say, "We've got this nifty template here called a face that will do that for you." The user says, "template? - face?" You say, "Sure, a face has all kinds of neat properties (attributes): foreground, background, font family,.... And it is a variable - you can change its properties, and then all the text with that face will reflect that change. The user says, "I just want to make this text be fixed pitch." You say, "Sure, but you need a face for that - we have one here just for that job, `fixed-pitch'." The point is, you don't need a face for that - at least not conceptually, from the user's point of view. Introducing faces (here) just complicates the UI for no gain. You stated, "For 'fixed pitch', I think that can only be considered as a face." That's wrong; the user need not jump through the hoop of considering it a face - no more than s?he must do that for bold. If s?he can think of applying boldness without conceiving of a bold face, she can do likewise for applying fixed-pitchness. How we actually implement "applying fixed-pitchness" is another story. We're talking user mental model here - keep that as simple as possible, as long as it is sufficiently accurate for the task at hand. At some point, it might be that a user needs to know that the quality of fixed-pitchness was actually "applied" by using a face - at that point, the concept can be introduced. This (applying boldness etc.) is a very simple interaction for users. Occam says not to make them conceive of more machinery than necessary to get the job done, even if there is a wonderful wizard or a "machine a gaz" behind the curtain. That's what the name is meant to be used for. Sure it is (although faces are not constants). But most faces are not named for their appearance; this is an exception. Introducing fixed-pitch *as a face* unnecessarily complicates things conceptually, and creates an exception in the UI. There is no reason for it. Let users think of it the same way they think of boldness - as a text property (or as a font family - see below). A face is a variable; its value is not in any way tied to its name. Users need to think about faces differently than they think about text properties. Usually, when a user wants to make some text be fixed pitch, s?he thinks in terms of changing the font or its style or its text properties (call it what you will - we are talking about user conception here, not implementation or formal definition). There is no notion of "face" in most UIs, and it is not necessary to introduce it here either, just to let users apply a fixed pitch to selected text. We can treat fixed pitch vs variable pitch the same way boldness is treated - for the user. There will still be a `Face...' menu item that lets users get to faces, including fixed-pitch. We're not holding anything back from them. But simply making some text be fixed pitch *requires* no notion of face. It is the monospace (fixed pitch) font property that a user wants to apply to text in this case, There is no such "font property". Some fonts are fixed pitch, and some are not. Some fonts are bold and some are not, also. Call it what you like. The point is that font family is, like boldness, a text style, from a user point of view. The fact that we have a face that uses that font family does not mean that wanting to make text fixed pitch means wanting to use that face. How we make the user's selection bold or fixed pitch is something s?he usually doesn't care about. In most UIs, you simply select the text and pick a font for it from a menu, or hit a Bold button. Now, it's true that when you "apply fixed-pitchness" to some text its appearance can change quite a bit. Another way to think about the change is as a font change (which is what it really is). It's true that applying boldness does not change the font family, while making text fixed pitch usually does - font family is the only face attribute that fixed-pitch defines, and fixed-pitch is the only one of the text "properties" in this menu that involves the font family. I have no quarrel with removing fixed-pitchness from the Text Properties menu altogether (except as a face in the `Face...' display), and leaving it available as a font family (e.g. Courier) in the font menu. My point is that it *could* be handled simply as a text property (conceptually), and users need not treat it as an exception - as a face, when they apply it. I was only addressing fixed-pitch because you brought it up as being impossible to use except as a face. My preference is to remove it from the menu, but if you want it, it can be treated the same as boldness.