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

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

[Drew Adams]

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

See http://emacs.stackexchange.com/a/27527/105: the user wants to use a

different face from face `variable-pitch'.  That seems reasonable.

 

Please consider adding an optional FACE argument, defaulting to face

`variable-pitch'.

 

In GNU Emacs 24.5.1 (i686-pc-mingw32)

of 2015-04-11 on LEG570

Windowing system distributor `Microsoft Corp.', version 6.1.7601

Configured using:

`configure --prefix=/c/usr --host=i686-pc-mingw32'

 

[-- Attachment #2: Type: text/html, Size: 3772 bytes --]

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 722 bytes --]

On 2016-10-02 23:22, Drew Adams wrote:
> See http://emacs.stackexchange.com/a/27527/105: the user wants to use a
> different face from face `variable-pitch'.  That seems reasonable.

That's not how I read it.  I think they just want to change the look of Emacs after invoking variable-pitch-mode, and customizing the variable-pitch face seems like the right approach for that.

> Please consider adding an optional FACE argument, defaulting to face
> `variable-pitch'.

I don't really see why the function should be called variable-pitch-mode any more.  Maybe select-buffer-face? IIUC this wouldn't have anything to do with variable pitches any more, except for the default value, maybe?

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Drew Adams]

> > See http://emacs.stackexchange.com/a/27527/105: the user wants to use a
> > different face from face `variable-pitch'.  That seems reasonable.
> 
> That's not how I read it.  I think they just want to change the look of
> Emacs after invoking variable-pitch-mode, and customizing the variable-pitch
> face seems like the right approach for that.

The question as posed is ambiguous, but it specifically asks how to use a different face.  The answer I gave spoke to both possible interpretations of the question.

> > Please consider adding an optional FACE argument, defaulting to face
> > `variable-pitch'.
> 
> I don't really see why the function should be called variable-pitch-mode any
> more.  Maybe select-buffer-face? IIUC this wouldn't have anything to do with
> variable pitches any more, except for the default value, maybe?

Agreed.  Unless there is some particular use for limiting the accepted FACE to variable-pitch faces.  In that case, additional logic/control would be needed.

Was there some particular reason that a mode was written specifically for variable-pitch (whether the face `variable-pitch' or variable-pitch faces in general), rather than providing a mode for any face?  If not then agreed: a name change would be appropriate.

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

[Eli Zaretskii]

> Date: Sun, 2 Oct 2016 20:48:19 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> > > See http://emacs.stackexchange.com/a/27527/105: the user wants to use a
> > > different face from face `variable-pitch'.  That seems reasonable.
> > 
> > That's not how I read it.  I think they just want to change the look of
> > Emacs after invoking variable-pitch-mode, and customizing the variable-pitch
> > face seems like the right approach for that.
> 
> The question as posed is ambiguous, but it specifically asks how to use a different face.

No, he asks how to use a different _font_, and customizing the face
(as you have suggested there) is the way to achieve that.

> > > Please consider adding an optional FACE argument, defaulting to face
> > > `variable-pitch'.
> > 
> > I don't really see why the function should be called variable-pitch-mode any
> > more.  Maybe select-buffer-face? IIUC this wouldn't have anything to do with
> > variable pitches any more, except for the default value, maybe?
> 
> Agreed.  Unless there is some particular use for limiting the accepted FACE to variable-pitch faces.  In that case, additional logic/control would be needed.

We already have buffer-face-mode.

> Was there some particular reason that a mode was written specifically for variable-pitch (whether the face `variable-pitch' or variable-pitch faces in general), rather than providing a mode for any face?  If not then agreed: a name change would be appropriate.

The variable-pitch face is a very general face: it stands for a face
using any variable-pitch font, of which there are gazillions.

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

[Drew Adams]

> We already have buffer-face-mode.

Not really the same.

> > Was there some particular reason that a mode was written specifically for
> variable-pitch (whether the face `variable-pitch' or variable-pitch faces in
> general), rather than providing a mode for any face?  If not then agreed: a
> name change would be appropriate.
> 
> The variable-pitch face is a very general face: it stands for a face
> using any variable-pitch font, of which there are gazillions.

A single face.  The face is hard-coded in the command.  You cannot
use the command with a different face.  Being able to customize
a face is something else altogether.

And no, there is nothing special about face `variable-pitch'.  In
particular, there is nothing that prevents you from customizing it
to a fixed-pitch face.

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

[Eli Zaretskii]

> Date: Mon, 3 Oct 2016 06:36:03 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: clement.pit@gmail.com, 24594@debbugs.gnu.org
> 
> > The variable-pitch face is a very general face: it stands for a face
> > using any variable-pitch font, of which there are gazillions.
> 
> A single face.

Yes, a mode that was made for using a single face.  There's nothing
wrong about that.

> The face is hard-coded in the command.  You cannot use the command
> with a different face.  Being able to customize a face is something
> else altogether.

Yes, I understood that the first time.  Reiterating this doesn't help
in any way.

> And no, there is nothing special about face `variable-pitch'.  In
> particular, there is nothing that prevents you from customizing it
> to a fixed-pitch face.

Of course.  But why would one want to do that?  It's like customizing
a color named "black" to have the same appearance as "white".

Anyway, looks like one more of those arguments that go nowhere, so I'm
out.

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

[Drew Adams]

> > > The variable-pitch face is a very general face: it stands for a face
> > > using any variable-pitch font, of which there are gazillions.
> >
> > A single face.
> 
> Yes, a mode that was made for using a single face.  There's nothing
> wrong about that.

Your statement was not about the mode, and neither was my reply to it.
It was about your claim that the face "stands for a face using any
variable-pitch font...".

How a face stands for a face, I don't know.  But there is nothing
more general about this face than any other face.  It, like others,
is entirely customizable.

Nor is it more restrictive than other faces.  As I mentioned, you
can easily customize it to NOT be variable-pitch.

> > The face is hard-coded in the command.  You cannot use the command
> > with a different face.  Being able to customize a face is something
> > else altogether.
> 
> Yes, I understood that the first time.  Reiterating this doesn't help
> in any way.

You mentioned the ability to customize the face as somehow obviating
the command being restrictive (hardcoded to one particular face).
I replied that customizing the face is something else altogether -
irrelevant here.

> > And no, there is nothing special about face `variable-pitch'.  In
> > particular, there is nothing that prevents you from customizing it
> > to a fixed-pitch face.
> 
> Of course.  But why would one want to do that?  It's like customizing
> a color named "black" to have the same appearance as "white".

Who said that one should want to do that?

Naming a face after any of its default attributes (e.g. `red-foreground')
is misguided.

But that's not the point here.  This was in reply to your statement that
face `variable-pitch' "stands for a face using any variable-pitch font."

It doesn't stand for any particular set of faces, at least not according
to the code.  It is just a face like another - entirely customizable.

It might be interesting to have a face whose customization is limited
to variable-pitch fonts.  But (so far anyway) `variable-pitch' is not
that face.

> Anyway, looks like one more of those arguments that go nowhere, so I'm
> out.

Likewise.  You brought in extraneous stuff, to which I replied,
hoping it might help.  I should know better by now, I guess.

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

[npostavs]

severity 24594 wishlist
quit

Drew Adams <drew.adams@oracle.com> writes:
>> I don't really see why the function should be called variable-pitch-mode any
>> more.  Maybe select-buffer-face? IIUC this wouldn't have anything to do with
>> variable pitches any more, except for the default value, maybe?
>
> Agreed.  Unless there is some particular use for limiting the accepted
> FACE to variable-pitch faces.  In that case, additional logic/control
> would be needed.

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

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

[Drew Adams]

> 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.

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

[npostavs]

tags 24594 moreinfo
quit

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

>
> As you can tell, I don't care much about this one way or
> another.  I don't use it and likely never will.

That's the crux of the issue, I think.  You can't effectively report a
subjective bug/feature request like this when you don't care about it.

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

[Drew Adams]

> > As you can tell, I don't care much about this one way or
> > another.  I don't use it and likely never will.
> 
> That's the crux of the issue, I think.  You can't effectively report a
> subjective bug/feature request like this when you don't care about it.

I did not say I don't care about it.  I said I don't care much
about it.

I cared enough about it - for Emacs (even though I don't use it) -
that I reported it.  And I spent time clarifying questions raised.

Please show how you think the bug/feature has not been effectively
reported.  Is there still something about it that is not clear
to you?

Anyway, it has been reported.  If no one cares enough about it to
fix it, so be it.  That does not imply that it was not reported
effectively.

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

[Noam Postavsky]

On Wed, Oct 5, 2016 at 11:14 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> > As you can tell, I don't care much about this one way or
>> > another.  I don't use it and likely never will.
>>
>> That's the crux of the issue, I think.  You can't effectively report a
>> subjective bug/feature request like this when you don't care about it.
>
> I did not say I don't care about it.  I said I don't care much
> about it.
>
> I cared enough about it - for Emacs (even though I don't use it) -
> that I reported it.  And I spent time clarifying questions raised.
>
> Please show how you think the bug/feature has not been effectively
> reported.  Is there still something about it that is not clear
> to you?

Why aren't the buffer-face-* commands sufficient?

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

[Drew Adams]

> 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.)

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

[Noam Postavsky]

On Wed, Oct 5, 2016 at 11:51 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> 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."

It wasn't clear that this was a serious suggestion, since obviously
"remove this feature because *I* will never use it" isn't enough to
get a feature removed from Emacs.

>
> 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.

Hmm, it looks like there is no way from lisp to tell if a face (or
font) is variable-pitch or not. Could be something useful to have in
and of itself.

>
> 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.)

Before deciding if something is really needed/wanted, we would have to
see what people use the feature for. You can't provide that
information since you don't use it.

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

[Drew Adams]

> > 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.
> 
> Hmm, it looks like there is no way from lisp to tell if a face (or
> font) is variable-pitch or not. Could be something useful to have in
> and of itself.

I was thinking the same thing, but was unsure how this might
be done (e.g., whether it is possible now).

> > 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.)
> 
> Before deciding if something is really needed/wanted, we would have to
> see what people use the feature for. You can't provide that
> information since you don't use it.

Agreed.  Which is why I proposed to improve it, unless
someone (else) can decide that it should just be removed.

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

[Glenn Morris]

Eli Zaretskii wrote:

> Of course.  But why would one want to do that?  It's like customizing
> a color named "black" to have the same appearance as "white".
>
> Anyway, looks like one more of those arguments that go nowhere, so I'm
> out.

I can't see this leading anywhere, boldly closing.