From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: RE: Re: 23.0.50; Middle ``wZZ in of permissions in dired-mode is red and bold: dired-warning Date: Sat, 13 Oct 2007 22:40:21 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1192340519 22140 80.91.229.12 (14 Oct 2007 05:41:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Oct 2007 05:41:59 +0000 (UTC) Cc: rudalics@gmx.at, emacs-pretest-bug@gnu.org To: "Eli Zaretskii" , "Peter Dyballa" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 14 07:41:48 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IgwET-0002lj-Lf for ged-emacs-devel@m.gmane.org; Sun, 14 Oct 2007 07:41:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgwEM-0003hj-TG for ged-emacs-devel@m.gmane.org; Sun, 14 Oct 2007 01:41:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IgwEJ-0003eM-8k for emacs-devel@gnu.org; Sun, 14 Oct 2007 01:41:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IgwEG-0003ar-I8 for emacs-devel@gnu.org; Sun, 14 Oct 2007 01:41:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgwEG-0003an-Cf for emacs-devel@gnu.org; Sun, 14 Oct 2007 01:41:32 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IgwEG-0002st-4c for emacs-devel@gnu.org; Sun, 14 Oct 2007 01:41:32 -0400 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IgwEF-0005Dj-If for emacs-pretest-bug@gnu.org; Sun, 14 Oct 2007 01:41:31 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1IgwEC-0002sH-EF for emacs-pretest-bug@gnu.org; Sun, 14 Oct 2007 01:41:31 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IgwEB-0002rY-En; Sun, 14 Oct 2007 01:41:27 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l9E5fDpA011149; Sun, 14 Oct 2007 00:41:14 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l9DM0KRM027779; Sat, 13 Oct 2007 23:41:12 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-80-53.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3291462241192340421; Sat, 13 Oct 2007 22:40:21 -0700 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.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:80838 gmane.emacs.pretest.bugs:20126 Archived-At: > With my latest change, you can do that by customizing the new face > dired-warn-writable. Good. So we've come almost full circle. There was already a separate face for this in the original (dired+.el), except that the face did not have a name that included "warn" (what are you WARNING about, anyway?). In the original, there was a separate face for each file privilege: read, write, execute (and also dir, link, and rare (bcsmpS)). There was no association of a warning with writable files. And there still is no need for any warning or for any alarmingly bright face for a write permission. The attempt to reuse `font-lock-warning-face' for the totally unrelated purpose of a file permission was misguided. After people complained and sensed that that was a mistake, someone changed it briefly from `font-lock-warning-face' to `font-lock-comment-delimiter-face'. That was just as misguided. The problem was not just that a bright red face was inappropriate; the problem was that there was no dedicated face for this, so users had to reuse some existing face. And now we still see "warn" in the face name, presumably for purely legacy reasons. What's that about? There is a lesson in this. The real mistake was trying to avoid defining separate faces for the different font-lock components of the Dired display. I don't know what motivates such behavior, but I see it repeated over and over. Perhaps it's for reasons of presumed economy; if so, it is a false economy. I really don't understand this propensity to reuse faces in contexts that have no semantic connection. What if a user has a completely different frame background for programming modes and for Dired? Dired has no notion of comments, so why coopt a comment face to use in Dired? And what does a warning have to do with a write permission? These things are totally unrelated, but they end up being related by force because some implementors are too conservative in creating new faces. This artificial reuse produces unnecessary coupling - making a user search for a face that fits both a file permission and either warnings or code commenting - good luck! There is no logical connection, and there is no reason to impose a connection. Even now, after you have removed that coupling (thank you), there remains a vestigial trace of it in the "warn" name you still use - `dired-warn-writable'? Yuck! It is of course OK to reuse an existing face as a default value for a new face. But I don't understand why there is so much resistance to defining new faces. People have used dired+.el for over a decade without reporting any problem with the faces - they could do what they wanted with them. The only user requests wrt dired+.el faces over the years were for more, not fewer, to distinguish additional aspects of the display. The last such request I received was just this past September - for his own use, a user added a new font-lock pattern and a new face, to color the whole file name when the file was of a certain type. I chose not to add that to dired+.el, but it shows that users want more control over the appearance, not less. [Wager: The day we add an easy, interactive, WYSIWYG way for users to define some of their own font-locking (that would be a useful feature, IMO), they will font-lock more, not less.] Make it easy for people to customize the appearance as they like, by having separate faces for logically separate components. A warning and a file-permission indicator have nothing in common. If you find yourself coupling such things, you are likely making a mistake. Wrt those who are annoyed by "too much" such Dired highlighting: I haven't checked how this was recently implemented in vanilla Emacs, but in dired+ it is relegated to a second level of highlighting, so you see it only if you choose `font-lock-maximum-decoration'. And of course all Dired highlighting goes away if you turn off `font-lock-mode'. I'd hope that there is similar user control in vanilla Emacs now: from customizing individual Dired faces, to choosing a font-lock level, to turning font-lock off altogether. FWIW, dired+ is here: http://www.emacswiki.org/cgi-bin/wiki/DiredPlus.