all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: 11139@debbugs.gnu.org
Subject: bug#11139: 24.0.94; inappropriate `face' property for `apropos*' button types
Date: Sat, 31 Mar 2012 10:27:00 -0700	[thread overview]
Message-ID: <0A1B281D1742437983A7AE45AABFFDA7@us.oracle.com> (raw)

Here's the thing: Users can customize faces.
 
That seems to get forgotten sometimes.
 
In the case of an Apropos buffer, Emacs defines multiple button types,
and all but one of them use _hard-coded_ faces.  And there are
additional places where particular faces are hard-coded in `apropos.el'.
This hard-coding is a no-no.
 
Why? Because USERS CAN CUSTOMIZE FACES.
 
A user might well customize some of the faces that you use here in a
hard-coded way.  Those customizations might make sense for typical uses
of those faces (e.g. font-locking for code), but the result in this
buffer might be awful.
 
You, writing apropos.el, cannot foresee all of the possibilities.  But
you can foresee that users will want to customize the appearance of
Apropos buffers.  And they deserve to be able to do that easily.
 
Please, please provide a way for users to customize the display of
Apropos itself.  Add apropos-specific deffaces or face-valued defcustoms
for each of the faces that the Apropos display uses.
 
Set their default values to whatever you like, including perhaps
font-lock faces.  But please stop hard-coding faces, depriving users of
the ability to control the appearance (without resorting to redefining
the Emacs source code).
 
A face should almost never be hard-coded, fixing Emacs's appearance in
concrete.  Please think of the users and of Emacs's mission to be
customizable by them.  It is hard to believe that this kind of thing is
still going on.  This is 2012, not 1980.
 
In GNU Emacs 24.0.94.1 (i386-mingw-nt5.1.2600)
 of 2012-03-19 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 






             reply	other threads:[~2012-03-31 17:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-31 17:27 Drew Adams [this message]
2012-04-01  0:50 ` bug#11139: 24.0.94; inappropriate `face' property for `apropos*' button types Wolfgang Jenkner

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=0A1B281D1742437983A7AE45AABFFDA7@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=11139@debbugs.gnu.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.