GNU bug report logs - #40750
Use error face for errors

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: "40750 <at> debbugs.gnu.org" <40750 <at> debbugs.gnu.org>, ndame <ndame <at> protonmail.com>
Subject: bug#40750: [External] : bug#40750: Use error face for errors
Date: Sat, 25 Sep 2021 15:46:44 +0000

> > I think having a face here would be interesting, even if it just
> > looks like the default face.  That would open the door for
> > experimentation in third-party themes, and perhaps they will
> > come up with some good ideas that we will want to imitate.
> 
> Yes, that's a good point.

I disagree.  Globally imposing a single face here,
even if by default it is face `default', is quite
the wrong thing to do.
___

What should be done, I think:

Add a user option, defaulting to no change from
the traditional behavior, which causes error and
warning messages to preserve text properties on
the strings they use.

That lets code construct error messages using
any faces (or no faces) that it judges are
appropriate for a given context.

The option gives users control.  By default
nothing is changed.  The non-default option
value gives code control over the appearance.
___

I said the same thing long ago wrt minibuffer
prompting, and that was unfortunately ignored.
As a result we now have a blanket treatment:
a single face for all minibuffer prompts.

Emacs can easily, and should, do better.  It
should provide more flexibility to code for
messaging.
___

I said the same thing long ago wrt completion
return values.  This was partially implemented,
at least.

Code should be able to control the appearance
of text it uses when interacting with users.
And users should be able to override this or
(better) configure it.

Previous Next

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