all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'David De La Harpe Golden'" <david@harpegolden.net>
Cc: 'Lars Magne Ingebrigtsen' <larsi@gnus.org>, 6693@debbugs.gnu.org
Subject: bug#6693: 24.0.50; font-lock-(builtin|doc) faces are *way* too close
Date: Mon, 4 Jul 2011 09:12:16 -0700	[thread overview]
Message-ID: <EF42F61E41854B84AFBC4AA2621974E5@us.oracle.com> (raw)
In-Reply-To: <4E11901A.3060408@harpegolden.net>

> > `font-lock-builtin-face' (":type", ":group")
> > `font-lock-doc-face'     (the doc strings)
> > `font-lock-keyword-face' ("defcustom")
> >
> > But especially the first two of these are close.
> 
> Hmm. Looking at your screenshot reminded me: but then what about 
> font-lock-comment-face (Firebrick)? Do you also see it as a bit too 
> close to font-lock-doc-face (VioletRed4), but from the other 
> direction (on the hue wheel)?

All three of these are close: 

font-lock-variable-name-face
font-lock-doc-face
font-lock-comment-face

However, I personally am not bothered by those similarities.

Again, personally I see font-lock mostly with Emacs-Lisp code, so I might not be
the best one to ask.

There is almost never any problem confusing a comment with a string (in Emacs
Lisp).  I suppose that a string and a comment on the same line might be
confusable, but in practice I don't think there is a problem here (worth trying
to fix, possibly messing up other things).

Similarly, I don't see a significant problem from the similarity between
`font-lock-variable-name-face' and the others, because of context.

Yidong makes the argument (essentially) that we should not take context into
consideration, since faces can inherit from the font-lock faces.  IMHO, that is
rather a problem with inheriting faces (esp. inheriting willy nilly), but we've
been through that discussion before and I know that I will not be able to
convince you (pl.) about that.

Wrt `font-lock-builtin-face', I say go for it: make some change and see what
happens.  My guess is that medium blue would be better than royal blue, but do
what you think is best.

I'm pretty much done here.  I mainly wanted to draw your attention to the
problem, reporting the color similarity for built-in and doc (and my personal
preference for the previous situation (Orchid)).  Fix the problem as you see
fit, and we'll see then whether anyone has a better approach etc.

I should probably have said that a second problem I have with the MediumViolet4
choice for the builtin face is that it does not stand out from black - IOW, it
is not sufficiently noticeable, for keywords.  That's no doubt another reason
why I preferred Orchid, and a reason why my argument about differing contexts
doesn't mitigate the problem here.

In sum (for the second problem): builtin doesn't stand out enough, and I don't
(personally) care whether it is "too light" (e.g. Orchid).  What's important for
something like keywords is that they stand out.






  reply	other threads:[~2011-07-04 16:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21 17:32 bug#6693: 24.0.50; font-lock-(builtin|doc) faces are *way* too close Drew Adams
2011-07-03 13:06 ` Lars Magne Ingebrigtsen
2011-07-03 13:58   ` Drew Adams
2011-07-03 14:05     ` Lars Magne Ingebrigtsen
2011-07-03 14:34       ` Drew Adams
2011-07-03 14:46         ` Lars Magne Ingebrigtsen
2011-07-03 15:09           ` Drew Adams
2011-07-04  0:52         ` David De La Harpe Golden
2011-07-04  2:32           ` Chong Yidong
2011-07-04  5:15             ` Drew Adams
2011-07-04  5:27               ` Chong Yidong
2011-07-04  5:02           ` Drew Adams
2011-07-04 10:04             ` David De La Harpe Golden
2011-07-04 16:12               ` Drew Adams [this message]
2011-07-04 17:01           ` Stefan Monnier
2011-07-05 14:24             ` Lars Magne Ingebrigtsen
2011-07-05 15:24               ` Chong Yidong
2011-07-05 15:29                 ` Lars Magne Ingebrigtsen

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=EF42F61E41854B84AFBC4AA2621974E5@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=6693@debbugs.gnu.org \
    --cc=david@harpegolden.net \
    --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 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.