GNU bug report logs - #11139
24.0.94; inappropriate `face' property for `apropos*' button types

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11139 in the body.
You can then email your comments to 11139 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.94; inappropriate `face' property for `apropos*' button types
Date: Sat, 31 Mar 2012 10:27:00 -0700

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'
 

Message #8 received at 11139 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Jenkner <wjenkner <at> inode.at>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 11139 <at> debbugs.gnu.org
Subject: Re: bug#11139: 24.0.94;
	inappropriate `face' property for `apropos*' button types
Date: Sun, 01 Apr 2012 02:50:51 +0200

On Sat, Mar 31 2012, Drew Adams wrote:

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

May I ask a rhetorical question: What's wrong with

#+begin_src emacs-lisp
(add-hook 'apropos-mode-hook
	  (lambda ()
	    (face-remap-set-base 'italic '(:reverse-video t))))
#+end_src

It's rhetorical because you already made it clear that a new load of
defface's or defcustom's would be the proper way to handle the issue.

My question is also rhetorical and hypocritical because I really just
wanted to seize on the opportunity to say that some people don't
actually enjoy wading through an ever growing plethora of options and
faces.

On the other hand, they revel in general mechanisms like face-remap-*.

YMMV ;-)

Wolfgang

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.