bug#12000: 24.1.50; do not hard-code `bold' font for help output

bug#12000: 24.1.50; do not hard-code `bold' font for help output

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

Please, please, please stop hard-coding faces.  You take power and
control away from users, and such an approach is short-sighted (if not
lazy). 
 
Look at the attached screenshot, which shows the links to minor-mode
sections of the *Help* buffer in the output of `describe-mode'.  Do you
find it readable with all that bold text?  No, of course not.  And the
annoyance is multiplied by the fact that a huge, run-on paragraph of
consecutive links is all in bold.  (That run-on paragraph of links is
itself bad design, but that's another story.)
 
Yet the font used in the screenshot is a very good one in general - just
contrast the non-bold words in the screenshot with the NOISYUGLINESS of
the rest.  The font is good, but it does not support boldness well.  And
that is actually pretty common.
 
Bold is a bad choice even for a default face, because many good fonts do
not support it well.  But especially is it horrible to hard-code the
choice.  Hard-coding faces in Emacs code should be verboten, requiring a
special dispensation from the UN Secretary General or RMS.
 
This is the font used in the screen shot, FYI:
"-outline-Lucida
Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1"
 
Please give users a new face intended to be appropriate to the
particular use, so they can customize just that use case.  Here, the use
is as a link in *Help* text, and the hard-coded face is `bold'.
 
Providing specific faces for given use cases means more faces, in
general.  But that does not stop you from providing a default appearance
for a new face that, say, inherits from an existing face.  Even (GNU
forbid!) from face `bold'.
 
The important thing is for users to be able to customize one use case,
without affecting other use cases all over the place.  You should not
require a user to customize face `bold' just for this particular use,
with the attendant side effect that it also changes the appearance in
other, unrelated contexts.
 

In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-07-16 on MARVIN
Bzr revision: 109106 fabian@anue.biz-20120716171839-0dv19ib9h6vfggfn
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
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 

[-- Attachment #2: throw-ugly-bold.png --]
[-- Type: image/png, Size: 13153 bytes --]

bug#12000: 24.1.50; do not hard-code `bold' font for help output

[Drew Adams]

Two things to add, for clarification:

1. There is an overlay on this text that uses face `button'.  But face `bold' is
also used on the text, and is hard-coded in `describe-mode':

(add-text-properties 0 (length pretty-minor-mode)
                     '(face bold) pretty-minor-mode)

It is the hard-coding of `bold' here that is objectionable.


2. The screenshot I sent was actually from Emacs 23.3.  But the problem has not
changed for Emacs 24 (hard-coded face `bold' remains).

The only difference is that now face `button' inherits from face `link', so the
appearance is a bit different (blue, not black).

bug#12000: 24.1.50; do not hard-code `bold' font for help output

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> 2. The screenshot I sent was actually from Emacs 23.3.  But the problem has not
> changed for Emacs 24 (hard-coded face `bold' remains).
>
> The only difference is that now face `button' inherits from face `link', so the
> appearance is a bit different (blue, not black).

If you have a font installed that has an ugly/unreadable bold variant,
the fix here is to install a better font.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#12000: 24.1.50; do not hard-code `bold' font for help output

[Drew Adams]

> > 2. The screenshot I sent was actually from Emacs 23.3.  But the
> > problem has not changed for Emacs 24 (hard-coded face `bold' remains).
> >
> > The only difference is that now face `button' inherits from face
> > `link', so the appearance is a bit different (blue, not black).
> 
> If you have a font installed that has an ugly/unreadable bold
> variant, the fix here is to install a better font.  Closing.

No.  The bug, as stated in the subject line and the bug report,
is hard-coding `bold'.

The fix is to stop such hard-coding.  Reopening.

bug#12000: 24.1.50; do not hard-code `bold' font for help output

[Bastien]

Drew Adams <drew.adams@oracle.com> writes:

> No.  The bug, as stated in the subject line and the bug report,
> is hard-coding `bold'.

I'd consider this a design choice, not a bug.

-- 
 Bastien

bug#12000: 24.1.50; do not hard-code `bold' font for help output

[Drew Adams]

> > No.  The bug, as stated in the subject line and the bug report,
> > is hard-coding `bold'.
> 
> I'd consider this a design choice, not a bug.

If it's by design then it is a design bug.  There is no need
to hard-code things like this.  Hard-coding takes power and
freedom away from Emacs users.  It just puts obstacles in their
way.  And typically, like here, gratuitously, with no gain.

bug#12000: 24.1.50; do not hard-code `bold' font for help output

[Bastien]

Drew Adams <drew.adams@oracle.com> writes:

>> > No.  The bug, as stated in the subject line and the bug report,
>> > is hard-coding `bold'.
>> 
>> I'd consider this a design choice, not a bug.
>
> If it's by design then it is a design bug.  There is no need
> to hard-code things like this.  Hard-coding takes power and
> freedom away from Emacs users.  It just puts obstacles in their
> way.  And typically, like here, gratuitously, with no gain.

Please fill this as a feature request.

While people are fixing bugs before a release, such bug reports
are a distraction.

-- 
 Bastien