all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "Eli Zaretskii" <eliz@gnu.org>,
	"Peter Dyballa" <Peter_Dyballa@Freenet.DE>
Cc: rudalics@gmx.at, emacs-pretest-bug@gnu.org
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	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICKEJAEAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <umyumjqay.fsf@gnu.org>

> 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.

  reply	other threads:[~2007-10-14  5:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-13 18:02 23.0.50; Middle ``w´´ in of permissions in dired-mode is red and bold: dired-warning Peter Dyballa
2007-10-13 18:22 ` 23.0.50; Middle ``wŽŽ " martin rudalics
2007-10-13 18:41   ` Peter Dyballa
2007-10-13 19:44     ` 23.0.50; Middle ``w▌▌ " Glenn Morris
2007-10-13 20:37     ` Re: 23.0.50; Middle ``wŽŽ " Eli Zaretskii
2007-10-13 21:30       ` Peter Dyballa
2007-10-13 23:24         ` Miles Bader
2007-10-14  4:10           ` Eli Zaretskii
2007-10-14  4:03         ` Eli Zaretskii
2007-10-14  5:40           ` Drew Adams [this message]
2007-10-14 20:24             ` RE: Re: 23.0.50; Middle ``wZZ " Eli Zaretskii
2007-10-14 20:54               ` Drew Adams
2007-10-14 21:20                 ` Eli Zaretskii
2007-10-14 21:21               ` 23.0.50; Middle w " Juri Linkov
2007-10-14 22:20                 ` Eli Zaretskii
2008-03-13  2:19                   ` Juri Linkov
2008-03-13  4:21                     ` Eli Zaretskii
2008-03-13 10:37                       ` Juri Linkov
2008-03-13 20:16                         ` Eli Zaretskii
2008-03-14  1:07                           ` Juri Linkov
     [not found]                             ` <f7ccd24b0803140146m22e5305dy704d7415bc00f8cd@mail.gmail.com>
2008-03-14  8:48                               ` Juanma Barranquero
2008-03-14 21:30                                 ` Juri Linkov
2008-03-14 23:37                                   ` Juanma Barranquero
2008-03-15  0:17                                     ` Juri Linkov
2008-03-15  0:26                                       ` Juanma Barranquero
2008-03-14 12:12                             ` Eli Zaretskii
2008-03-14 22:45                     ` Chong Yidong
2008-03-15  0:16                       ` Juri Linkov
2008-03-15 14:27                         ` Eli Zaretskii
2008-03-15 16:20                           ` Juri Linkov
2008-03-15 18:30                             ` Eli Zaretskii
2008-03-15 14:10                       ` Eli Zaretskii
2008-03-15 16:20                         ` Juri Linkov
2008-03-15 20:44                           ` Stefan Monnier
2008-03-16 14:26                             ` martin rudalics
2008-03-16 16:29                             ` Juri Linkov
2007-10-15  0:49               ` 23.0.50; Middle ``wZZ " Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICKEJAEAAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=Peter_Dyballa@Freenet.DE \
    --cc=eliz@gnu.org \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.