GNU bug report logs - #24594
24.5; `variable-pitch-mode': accept FACE arg instead of hardcoding the face

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: npostavs <at> users.sourceforge.net
Cc: 24594 <at> debbugs.gnu.org, Clément Pit--Claudel <clement.pit <at> gmail.com>
Subject: bug#24594: 24.5; `variable-pitch-mode': accept FACE arg instead of hardcoding the face
Date: Tue, 4 Oct 2016 20:28:11 -0700 (PDT)

> Doesn't this already exist as buffer-face-set?

Not really.  Nor is it `buffer-face-mode'.
The closest is `buffer-face-toggle'.

FWIW, I'm OK with eliminating `variable-pitch-mode'
altogether.  I don't really see the point of a version
of `buffer-face-mode' that is limited to one face.

Likewise, eliminating face `variable-pitch' - fine by
me.  As I said earlier, faces should not be named after
some default value of an attribute (e.g. `red-foreground'
face or `variable-pitch' face).

But if there is some good reason why we should have a
`variable-pitch-mode' and a face that REALLY is limited
to variable-pitch fonts, then the defface should actually
limit the attribute values so that the face is always a
variable-pitch face.

IF we should have a `variable-pitch-mode' then I think
it should accept a face argument.

One way to make it possible to specify the face
interactively would be to have a specific kind of non-nil
prefix arg prompt you for a face name (`read-face-name').

For more-or-less backward compatibility (not that
anyone has used the command, perhaps) would be to have
a negative prefix arg prompt for the face name (as well
as turning on the mode).

As you can tell, I don't care much about this one way or
another.  I don't use it and likely never will.  I don't
really see the point of it, as currently defined.
Whether it could prove to be useful if improved a bit,
I don't know.

Previous Next

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