Re: [PATCH] Re: About the :distant-foreground face attribute

["Jan Djärv" <jan.h.d@swipnet.se>]

Hello.

14 jan 2014 kl. 19:47 skrev Daniel Colascione <dancol@dancol.org>:

> On 01/14/2014 03:44 AM, Jan D. wrote:
>> Daniel Colascione skrev 2014-01-14 11:44:
>>> On 01/14/2014 01:34 AM, Jan D. wrote:
>>>>>> Given the use case at hand, we know for a fact that the background is
>>>>>> the region background, so I don't understand why a calculated
>>>>>> foreground
>>>>>> is needed.  Just pick one that matches the background.
>>>>>> There might be other use cases where a calculated foreground makes
>>>>>> sense, but my imagination fails me here.
>>>>> 
>>>>> Calculated foreground colors look better: they resemble the font-lock
>>>>> colors on which they're based.
>>>> 
>>>> For the region case, that would imply the possibility of different
>>>> foregrounds for marked text, none which is the actual font-lock color.
>>> 
>>> It *is* the same color in the sense that the code we generate has the
>>> same hue. How on earth is that worse than changing arbitrary font-locked
>>> pieces of text to the system selection foreground color?
>> 
>> Because the system color foreground is (presumably) choosen to look good
>> together with the system color background.
> 
> Yes, and a color we algorithmically generate from a font-lock face will *also* look good against that background color, but 1) will be distinct from other faces replaced for lack of contrast, and 2) will be visually similar to the pre-highlight face. Have you tried the patch?

No.  If Emacs generates a color, Emacs desides what looks good.  If the system defines a color, the system (or the user if customized) desides what looks good.  I don't think it matters what I think about colors generated by your patch, I might even think they look better than many system defined colors.  But as a principle I think the desision is not Emacs to make *by default*.  Users may of course apply customizations to Emacs and change it.

> 
>>> But that's exactly what
>>> happens when we put gtk_selection_bg_color in a color spec! Why are you
>>> fine with allowing gtk_selection_bg_color as a color (producing a color
>>> that's presumably workable but unknown to a theme writer) but adamantly
>>> opposed to a feature that selects good colors another way?
>> 
>> I'm objecting to having the system default colors replaced with
>> generated colors for the default case.  What themes other than the
>> default does is irrelevant.  We are just talking about defaults here.
> 
> We already replace the system default colors with colors from font-lock faces.

We at least try to use text selection colors and tool tip colors where we can.  For some ports of Emacs this is harder (i.e. not using Gtk+).  I haven't seen any system defined colors that corresponds exactly to an Emacs font-lock face, Emacs defines tons of faces that most GUI system don't.  So yes, we replace system colors, when Emacs can't figure out the system color.  What else should Emacs do?

> 
>>> I've produced working code that allows Emacs to act how you prefer *and*
>>> how I prefer based on user configuration. What is your problem with that
>>> code?
>> 
>> I have no problem with the code, just the defaults.
>> 
>>> Have you responded to the numerous objections to
>>> :distant-foreground with anything other than retrenchment?
>> 
>> So far the objections have been mostly opinions.  If there was a
>> concrete case or a bug it exposes that would be another issue.
>> The most concrete objection is the case of inheriting faces Yidong
>> brought up in another mail, which indeed is a real problem.
> 
> Problems with usability in UI or API design don't result in clear "bugs" in the same way that logic errors or crashes do. Fixing them relies on judgment, and that relies chiefly on informed opinion. You can't dismiss others' opinions about this feature while not subjecting your own to the same treatment.

I have not put forth any usability or design argument for the current implementation, it is a bug fix plain and simple.  Informed opinion sounds like a copout to avoid having to motivate your opinion.  If you can't motivate your informed opinion, it is not worth anything.  Design can be motivated, and so can usability, there are tons of books on the subjects.  I have not read any such arguments here, just assertions that this is bad.
Take "attribute is to narrow".  It may very well be, but on what motivation?  How can I know if I want to add another attribute if it will be to narrow too?  Because person X and Y says so?  That would be OK if X and Y where appointed design chiefs for Emacs or this aspect of Emacs.  I don't think any value of X or Y has been so appointed, except for the Emacs maintainers.

> 
>>> And a theme designer can opt not to use the feature or to explicitly
>>> turn it off --- but a theme designer should never have to bother,
>>> because the feature only activates when the contrast is awful, which
>>> happens only when a theme designer screws up or deliberately relies on
>>> system colors.
>> 
>> Why should a theme designer rely on system colors?  That does not sound
>> like a good theme.  Again, the default should rely on system colors, not
>> arbitrary themes.
> 
> You are not responding to the point I make in the text you quote. I don't know why a theme designer would use system colors either. That's not the point. I'm saying that explicitly-chosen themes should never trigger the code under discussion if they're well-designed.

Okay.  I don't know why that is relevant though.

> 
>>>> That is not a use case.  A use case describes what an actual user does
>>>> and in what situation automatically calculates colors enters the
>>>> picture.
>>> 
>>> This entire thread describes the use case. There are abundant examples.
>>> Your objection here is baseless.
>> 
>> There is a lot of handwaving and describing of mechanisms, but not one
>> real world example, i.e. what major mode and which font lock faces and
>> possible other faces are involved, and what does the user do to trigger
>> the generated color.
> 
> Message-ID: <52D4A23E.4030802@dancol.org>
> From: Daniel Colascione <dancol@dancol.org>
>> So to put the discussion in more concrete terms: say I run a stock
>> GTK3 Emacs on a system with a background color exactly equal to
>> "Blue1", which is the color we use for font-lock-function-name-face.
>> I visit xfaces.c, search for "UNSPECIFIEDP", and hit C-a C-SPC C-e.
>> What colors do you propose we use for the text "UNSPECIFIEDP" on that
>> line?

You can do that today and see which color gets used.
It is the one Emacs trunk uses today, the Gtk selection foreground color.

> 
>> 
>>>>> :distant-foreground has far too narrow a justification to warrant being
>>>>> a face property by itself.
>>>> 
>>>> Also, just an opinion, not based on some documented design rule in any
>>>> Emacs or GNU document.
>>> 
>>> So only GNU documents count now, not reasoned arguments?
>> 
>> No, but if documentation of some design rule existed it would give
>> weight to your argument.  But your statement about :distant-foreground
>> being too narrow is just your personal opinion which you have not
>> motivated with any reasoned argument, just asserted.
> 
> I'm not the only one who's expressed concerns about the design of the feature.

Good, then you should be able to motivate your design rules with no effort.

	Jan D,