From: Drew Adams <drew.adams@oracle.com>
To: Noam Postavsky <npostavs@users.sourceforge.net>
Cc: 24594@debbugs.gnu.org, "Clément Pit--Claudel" <clement.pit@gmail.com>
Subject: bug#24594: 24.5; `variable-pitch-mode': accept FACE arg instead of hardcoding the face
Date: Wed, 5 Oct 2016 08:51:21 -0700 (PDT) [thread overview]
Message-ID: <c917bdcb-1fb6-4171-80b8-30ea21823e3c@default> (raw)
In-Reply-To: <CAM-tV-8=O4w59h7XxHCkGuh89nRO0hSa4T7qup_HUkARy141pw@mail.gmail.com>
> Why aren't the buffer-face-* commands sufficient?
Which part of this is unclear: "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."
That would be one "fix" for this bug report. Remove it,
and remove face `variable-pitch'.
On the other hand, if you do NOT eliminate it, then the
problems with it are still there to be fixed.
1. Enhancement: command should work for any variable-pitch
face.
One way to do that, so that you can interactively specify
the face to use, was proposed: negative prefix arg prompts
for the face.
2. Enhancement: Fix face `variable-pitch' so that it really
limits customization of the attributes to variable-pitch
faces. That is the only justification for a face name
that reflects particular attribute values: limit
customization for those values.
Again, the only reason to keep `variable-pitch-mode' and
face `variable-pitch' is if you feel that we really need
such things. (I do not.)
But if you do, then they cry out to be fixed properly,
IMO. IF they are so fixed, AND if it is true that a
variable-pitch specialization of the `buffer-face-*'
commands is useful (not my propos), THEN some Emacs
users will presumably benefit.
(I will not benefit, personally, since I do not use
such things.)
next prev parent reply other threads:[~2016-10-05 15:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-03 3:22 bug#24594: 24.5; `variable-pitch-mode': accept FACE arg instead of hardcoding the face Drew Adams
2016-10-03 3:39 ` Clément Pit--Claudel
2016-10-03 3:48 ` Drew Adams
2016-10-03 7:00 ` Eli Zaretskii
2016-10-05 0:16 ` npostavs
2016-10-05 3:28 ` Drew Adams
2016-10-05 12:29 ` npostavs
2016-10-05 15:14 ` Drew Adams
2016-10-05 15:32 ` Noam Postavsky
2016-10-05 15:51 ` Drew Adams [this message]
2016-10-05 21:43 ` Noam Postavsky
2016-10-06 16:24 ` Drew Adams
[not found] ` <<587cb6c7-44f8-4546-91ee-264416c965d6@default>
[not found] ` <<83oa31q5mr.fsf@gnu.org>
2016-10-03 13:36 ` Drew Adams
2016-10-03 14:12 ` Eli Zaretskii
2016-12-07 20:15 ` Glenn Morris
[not found] ` <<<587cb6c7-44f8-4546-91ee-264416c965d6@default>
[not found] ` <<<83oa31q5mr.fsf@gnu.org>
[not found] ` <<3a104ad1-ccf9-4b54-9773-e939d74aaac1@default>
[not found] ` <<83d1jhplmf.fsf@gnu.org>
2016-10-03 14:51 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c917bdcb-1fb6-4171-80b8-30ea21823e3c@default \
--to=drew.adams@oracle.com \
--cc=24594@debbugs.gnu.org \
--cc=clement.pit@gmail.com \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).