GNU bug report logs - #62370
28.1; sieve-mode: faces should inherit from font-lock-X-face faces

Previous Next

Full log

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

From: "Trent W. Buck" <trentbuck <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Gregory Heytings <gregory <at> heytings.org>, Eli Zaretskii <eliz <at> gnu.org>,
 62370 <at> debbugs.gnu.org
Subject: Re: bug#62370: 28.1; sieve-mode: faces should inherit from
 font-lock-X-face faces
Date: Thu, 23 Mar 2023 12:05:24 +1100

[Message part 1 (text/plain, inline)]

On Wed 22 Mar 2023 14:22:45 -0700, Jim Porter wrote:
> On 3/22/2023 1:10 PM, Gregory Heytings wrote:
> > But the sieve-* faces have existed for twenty years, so it's now too
> > late to change them.
>
> I think it might actually be ok to change this: the face attributes for each
> of the 'sieve-*' faces closely correspond to one of the 'font-lock-*-face'
> faces. They're not *identical*, but the differences are very slight.
>
> The mapping is:
>
>   sieve-control-commands -> font-lock-builtin-face
>   sieve-action-commands  -> font-lock-function-name-face
>   sieve-test-commands    -> font-lock-constant-face
>   sieve-tagged-arguments -> font-lock-keyword-face
>
> (Note that this is a different mapping from Trent's proposal.)

For the record, I'm fine with this mapping.
I only just started using sieve seriously yesterday, so
my initial mapping was a wild-ass guess.

> If we mapped the 'sieve-*' faces like that, I doubt anyone using the default
> theme would notice. Likewise, anyone using a theme that customizes the
> 'sieve-*' faces wouldn't notice, since they're already explicitly-themed.

I agree.

> The only users who would see an impact would be those using non-default
> themes that *didn't* have definitions for 'sieve-*' faces, and they'll
> arguably have improved visuals: with the change, 'sieve-mode' will look
> consistently-themed with the rest of Emacs.

I agree.

I don't think "I opened foo.sieve in Emacs 20 twenty years ago, and
now I opened foo.sieve in Emacs 30 today, and the colors aren't identical, and now I'm mad"
is a good argument for never changing the defaults.

Emacs changes the defaults like that ALL THE TIME.
If they piss me off, I just patch back in the old behaviour and forget about it.
Choice examples:

  ;; Colour comment bodies in console mode.  I tried to get this changed upstream,
  ;; but RMS decreed that it was a feature as (apparently) red is difficult to
  ;; read on eight-colour terminals.  Hopefully a circular dependency is OK...
  ;; FFS, RMS, just configure your terminal, e.g. printf '\033]P1CC0000\033]P9EF2929'
  (eval-after-load "font-lock"
    '(if (< emacs-major-version 24)
         (put 'font-lock-comment-face 'face-alias 'font-lock-comment-delimiter-face)
       ;; UPDATE: it's not OK in Emacs 24.  For now, just assume an 8-color tty.
       (set-face-attribute 'font-lock-comment-face nil :foreground "red")))

  ;; Undo stupid feature where ^M means ^J and ^J means ^M.
  ;; Fixes copy-paste between terminals without bracketed paste mode (i.e. ALL of them).
  ;; http://emacsredux.com/blog/2014/01/19/a-peek-at-emacs-24-dot-4-auto-indentation-by-default/
  (when (fboundp 'electric-indent-mode)
    (electric-indent-mode -1))

[signature.asc (application/pgp-signature, inline)]

Previous Next

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