unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 'David Koppelman' <koppel@ece.lsu.edu>, 13686@debbugs.gnu.org
Subject: bug#13686: hi-yellow vs. hi-lock-1
Date: Tue, 26 Feb 2013 20:58:10 -0800	[thread overview]
Message-ID: <527A8B2FB8E742F9AC4063C8B3957071@us.oracle.com> (raw)
In-Reply-To: <jwv7gluv8yk.fsf-monnier+emacs@gnu.org>

> > The main point is that it makes little sense for a face, which is
> > a variable thingy (changeable, customizable), to have a name that
> > suggests otherwise, i.e., suggests that it has some _particular_,
> > constant quality.
> 
> If the user sets the hi-yellow face to red, she gets what she 
> deserves.

Really?  What dos she deserve?  Are you saying that there is some reason she
should not customize the face?  Why use a face then?

> > The face name should reflect what the face is for - the kind of
> > highlighting or whatever that it does.
> 
> Agreed, and hi-yellow is for highlighting some text in yellow, hence
> its name.

If that's really what it's for, then the name is apt.

In that case, a customizable face is not what's needed.  Or else maybe one where
you somehow limit the customization regarding color for various attributes.

> The only real problem is that a user who wants to use a face whose
> attribute do not agree with any of the predefined hi-* faces might end
> up forced to use such a silly setting.

If you provide a customizable face where you don't want one, and you don't limit
it in any way, that's the silliness.  It is not silly for a user to use an
allowed value.
 
> So the right fix is to provide ways for the user to add her own faces.

That would not change the anomalous `hi-<color>' faces.  It would not prevent
the silly settings you mention.

> An alternative might be to let the user specify either a face name or
> a color name, so we can get rid of hi-yellow altogether.  But 
> that still only caters to "highlighting with a color", whereas faces
> offer more choices.

Let the user choose a color.  And let the user choose other attributes.

And if you're going to do all that, then just let the user customize faces,
which do not have any static, inherent colors, even if they might unfortunately
have a color in their names.

IOW, just rename the faces based on what they are really for, not on particular
colors.

Oh, but you said that "hi-yellow is for highlighting...in yellow".  In that
case, it is not also about using other face attributes.  Time to choose.






  parent reply	other threads:[~2013-02-27  4:58 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-11  6:14 bug#13686: 24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting) Jambunathan K
2013-02-15 15:03 ` Stefan Monnier
2013-02-15 18:29   ` David Koppelman
2013-02-15 20:39     ` Stefan Monnier
2013-02-26 23:11 ` bug#13686: hi-yellow vs. hi-lock-1 David Koppelman
2013-02-27  0:33   ` Drew Adams
2013-02-27  1:35     ` Stefan Monnier
2013-02-27  3:59       ` Jambunathan K
2013-02-27  4:58       ` Drew Adams [this message]
2013-02-27  5:10         ` Jambunathan K
2013-02-27  5:38           ` Drew Adams
2013-02-27  5:54             ` Jambunathan K
2013-02-27  6:01               ` Drew Adams
2013-02-27 23:45             ` Juri Linkov
2013-03-06 18:43               ` Jambunathan K
2013-03-06 19:54                 ` David Koppelman
2013-03-07  9:16                 ` Juri Linkov
2013-03-06 19:04             ` Jambunathan K
2013-02-27  3:49     ` Jambunathan K
2013-02-27 13:46       ` Stefan Monnier
2013-02-27 14:56         ` Jambunathan K
2013-02-27 16:27           ` Stefan Monnier
2013-03-06 18:56         ` Jambunathan K
2013-03-06 19:55           ` David Koppelman
2013-03-06 20:06             ` Jambunathan K
2013-03-07  0:54               ` David Koppelman
2013-03-07  3:23                 ` Jambunathan K
2013-03-09  1:33             ` Stefan Monnier
2013-03-09  2:47               ` Jambunathan K
2013-03-09  3:26                 ` Stefan Monnier
2013-04-08  5:31               ` Jambunathan K
2013-04-10  4:11                 ` Jambunathan K
2013-04-10 18:33                 ` David Koppelman
2013-04-11  4:24                   ` Jambunathan K
2013-02-27  3:36   ` Jambunathan K
2013-02-27  4:08   ` Jambunathan K
2013-11-15  4:45 ` bug#13686: 24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting) Jambunathan K

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=527A8B2FB8E742F9AC4063C8B3957071@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=13686@debbugs.gnu.org \
    --cc=koppel@ece.lsu.edu \
    --cc=monnier@iro.umontreal.ca \
    /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).