From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps Date: Tue, 13 Jan 2009 20:13:33 -0800 Message-ID: <005301c975fe$77866850$0200a8c0@us.oracle.com> References: <001c01c975b6$e2ecb0b0$0200a8c0@us.oracle.com> <87ab9u8ym1.fsf@jurta.org> Reply-To: Drew Adams , 1894@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1231907024 18049 80.91.229.12 (14 Jan 2009 04:23:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Jan 2009 04:23:44 +0000 (UTC) Cc: 1894@emacsbugs.donarmstrong.com To: "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 14 05:24:56 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LMxJH-0000g5-E4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Jan 2009 05:24:55 +0100 Original-Received: from localhost ([127.0.0.1]:51437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LMxI0-0001fC-Lw for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Jan 2009 23:23:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LMxHt-0001az-Ct for bug-gnu-emacs@gnu.org; Tue, 13 Jan 2009 23:23:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LMxHs-0001Zt-KV for bug-gnu-emacs@gnu.org; Tue, 13 Jan 2009 23:23:28 -0500 Original-Received: from [199.232.76.173] (port=55230 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LMxHs-0001ZX-H7 for bug-gnu-emacs@gnu.org; Tue, 13 Jan 2009 23:23:28 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:50174) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LMxHr-0007sQ-Ug for bug-gnu-emacs@gnu.org; Tue, 13 Jan 2009 23:23:28 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0E4NPtH002335; Tue, 13 Jan 2009 20:23:26 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n0E4K3iD001177; Tue, 13 Jan 2009 20:20:03 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 04:20:03 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 1894 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: notabug wontfix Original-Received: via spool by 1894-submit@emacsbugs.donarmstrong.com id=B1894.123190642032358 (code B ref 1894); Wed, 14 Jan 2009 04:20:03 +0000 Original-Received: (at 1894) by emacsbugs.donarmstrong.com; 14 Jan 2009 04:13:40 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0E4DbVB032352 for <1894@emacsbugs.donarmstrong.com>; Tue, 13 Jan 2009 20:13:38 -0800 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0E4Cwpo019940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2009 04:12:59 GMT Original-Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0E4DSEA022558; Wed, 14 Jan 2009 04:13:29 GMT Original-Received: from dradamslap1 (/141.144.161.46) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Jan 2009 04:13:26 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ab9u8ym1.fsf@jurta.org> Thread-Index: Acl157FYkEPKOBdPSceDGRZj8HULsAAEUo5A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.496D6668.006A:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 13 Jan 2009 23:23:28 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:24097 Archived-At: > > emacs -Q > > M-x set-variable special-display-regexps ("[ ]?[*][^*]+[*]") > > > > Customize `special-display-frame-alist' to, say, have > > `background-color' "LightBlue". M-x list-faces-display. > > > > The frame displaying buffer *Faces* does not show a LightBlue > > background. However, the `frame-parameters' for that frame > > do include (background-color . "LightBlue"). > > Please see a comment in `list-faces-display': > > ;; If the *Faces* buffer appears in a different frame, > ;; copy all the face definitions from FRAME, > ;; so that the display will reflect the frame that was selected. What does it mean? Is this about face definitions? I don't see why. I'm talking about the frame parameters - the appearance of the frame that is used to show the individual faces. Unless that comment is just some kind of a cop-out based on `default' being one of the faces to portray. How the individual faces, including face `default', are shown as samples is one thing - I have no problem with that. How the frame itself is displayed is what I have a problem with. If you feel you need to tweak things so that the portrayal of face `default' shows up in the sample list the way that face was defined for the previous frame, OK (I don't really care about that). But the attributes that face `default' has in the *Faces* frame should not override and interfere with the normal display of a buffer named `*Faces*'. And why would such an exceptional behavior - not respecting `special-display-regexps' - be explained only in a comment? How would a user of `list-faces-display' know about this odd behavior? IIRC, this change dates from when we started to treat face `default' as synonymous with the corresponding frame parameters (`background-color' etc.). IOW, it is more an _implementation side effect_ than a "feature". There is no reason, from a _users's_ point of view, to confuse the _portrayal_ of a face with the _use_ of that face to display a frame of face samples. Is this confusion of use and mention just a result of implementation laziness? Think about the UI from the user's point of view - and that includes the user's control of frame appearance using `special-display-regexps' (and `default-frame-alist' and ...). The _effect_, for the user, was coherent and clear in Emacs 20 (probably 21 also - haven't checked). Now the entire display changes, depending on whichever frame you call the command from. That's not helpful or needed - it's enough to show the `default' face's sample, like each of the other faces. In this case, it's not right to simply use that face to define the frame properties for the *Faces* frame. A proper fix would show the `default' face using its definition from the originating frame (if you consider that feature worthwhile - I don't care), and _label it as such_: "default (in frame blah-blah)", where only the name `default' is a link (underlined) to the face details. That information is completely missing for the user currently. But leave the frame's "face" parameters alone - treat it just as any other similar frame would be treated: if the `special-display-*' stuff applies, use that; otherwise use `default-frame-alist' or whatever else would normally take effect. This is poor UI, and it sounds like it might also represent lazy programming. My other comments should also be addressed: * About the appropriate frame "face" parameters appearing in certain circumstances (leaking in) - display portion after the buffer text, right side of minibuffer, showing full-frame ephemerally when you resize. Very ugly - obviously a bugged appearance. * About this "feature" being a mystery to users - explained only in a code comment. Put on your thinking caps as users, not just as implementors. There is a better way.