unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>,
	"'Lars Magne Ingebrigtsen'" <larsi@gnus.org>
Cc: 6117@debbugs.gnu.org, 'Chong Yidong' <cyd@stupidchicken.com>,
	jidanni@jidanni.org
Subject: bug#6117: 24.0.50; dired-marked-face same as dired-flagged-face
Date: Wed, 10 Aug 2011 06:45:46 -0700	[thread overview]
Message-ID: <D1102E5FD3D84F7AA83527450E8C004B@us.oracle.com> (raw)
In-Reply-To: <871uwt38q1.fsf@mail.jurta.org>

> >> Does anybody have a suggestion taken from the `font-lock-*' corpus?
> >
> > I picket a font-lock face at random.
> 
> This is a dangerous change.  It increases the likelihood of 
> deleting the wrong files, because its default color is not
> distinctive and visible enough to help preventing the wrong
> operation.

Yes.  Misguided.

> Moreover, depending on `font-lock-variable-name-face' with the hope
> that users never customize `font-lock-*' faces is a wrong assumption.
> After selecting a new color for variable names, the user later
> will discover an unpleasant effect that it have on other
> completely unrelated faces.

Yes.  Misguided.

> For instance, I customized `font-lock-variable-name-face' to "Blue1",
> and now I have the same colors for Dired directories and files flagged
> for deletion!

It is simply a bad idea to inherit from a font-lock face here.

And even in general, but that's another story.  But you came close to it above,
where you noted that "the user later will discover an unpleasant effect that it
have on other completely unrelated faces".

That "unpleasant effect" has nothing in particular to do with the case at hand,
but is a general problem with inheriting faces willy nilly.  But for the case at
hand, at least, it should be clear to all that this is a bad idea.

> If it's absolutely necessary to distinguish between marked and flagged
> files, then they should use colors closer to traditional, e.g.:
> 
> * for `dired-flagged' leave the old red face unchanged,
>   just like `compilation-error';
>
> * for `dired-marked' use the same face definition as for
>   `compilation-warning'.  Its orange color is very close
>    to `dired-flagged' but still distinctive.

That would be OK.  Same colors, but not via inheritance (else you get the same
problem you indicated above).

What's important is that:
a. Both faces be easily noticeable.
b. They be easily distinguished from each other.
c. The deletion flag be most noticeable.
   A "warning" color such as red is good for this,
   as it signals potential danger. 

FWIW, I use these:
Skyblue background for marked.
Red foreground for flagged.
Yellow-on-red for the `D' itself.
Yellow-on-blueviolet for the `*' itself.






  reply	other threads:[~2011-08-10 13:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-05 20:31 bug#6117: 24.0.50; dired-marked-face same as dired-flagged-face jidanni
2010-05-06 13:17 ` Stefan Monnier
2010-05-06 15:20   ` Drew Adams
2011-07-13 21:28   ` Lars Magne Ingebrigtsen
2011-07-13 22:28     ` Drew Adams
2011-07-16 19:53     ` Lars Magne Ingebrigtsen
2011-08-02 19:05       ` Lars Magne Ingebrigtsen
2011-08-10  9:45         ` Juri Linkov
2011-08-10 13:45           ` Drew Adams [this message]
2011-08-17 19:35             ` Juri Linkov
2011-08-17 21:36               ` Chong Yidong
2011-08-18 11:46                 ` Juri Linkov
2011-08-24 18:09                   ` Juri Linkov
2011-08-24 18:16                     ` Drew Adams
2010-05-06 20:57 ` Juri Linkov
2010-05-07  2:43   ` Drew Adams
2010-05-07 18:16     ` Juri Linkov
2010-05-10 18:45 ` bug#6163: 24.0.50; be sure the color of the mark matches that of the filename jidanni
2011-08-02 16:00   ` Lars Magne Ingebrigtsen
2011-08-17 20:02 ` bug#6117: 24.0.50; dired-marked-face same as dired-flagged-face jidanni

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=D1102E5FD3D84F7AA83527450E8C004B@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=6117@debbugs.gnu.org \
    --cc=cyd@stupidchicken.com \
    --cc=jidanni@jidanni.org \
    --cc=juri@jurta.org \
    --cc=larsi@gnus.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).