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

[Drew Adams <drew.adams@oracle.com>]

> >> If a user never expressed a preference with respect to foreground
> >> and background colors, there's no contract to violate.
> >
> > And how does she express that preference, if it happens to
> > coincide with the default colors?
> 
> See above.

So she has to opt out.  She has to realize that she really wants
the default color attribute values, which she never really sees
because the automatic tweaking is on by default.  And then she
has to explicitly opt out, to get those colors she has finally
realized she wants.

Just turn it off by default.  For those few platforms that are
ill-designed enough to present a problem, she will figure out
whether she wants to remedy that problem by opting into the
automatic twiddling.  If there really is a visible problem on
her platform then she will see it and will be able to make an
informed choice.  Call out this clever compensation in the doc.

> > What you are saying is like saying that you think you have a
> > license to change the value of option `default-frame-alist'
> > automatically, if the current value is nil, because that's also
> > the default value.
> 
> Well, yes, we do have such a license. By this logic, we can't change
> any default ever.

Did you notice "automatically" and "current value" in that sentence?
I'm not talking about the license of Emacs Dev to redefine the
_default_ value.  I'm talking about license to change the _current_
value of an option, on the fly, automatically, behind the user's
back... - just because the current value happens to coincide with
the default value (`nil' in this case).

A user's not customizing an option away from the default value is
not implicit permission for Emacs to twiddle the current value to
something different.

> >>> But it still makes life more complicated for Lisp code that
> >>> wants to get or set the actual appearance of the face.  Whereas
> >>> before code needed only to get or set attribute :foreground,
> >>> now it will need to also check for a non-nil :contrast-function
> >>> and apply that.
> >>
> >> I don't understand why lisp code would need to know the
> >> post-adjustment colors used for display. Can you explain why
> >> we'd want to know?
> >
> > Lisp code that checks or changes a given color attribute is trying
> > to check or affect the actual appearance of the face (again, not
> > considering merges with other faces etc.).
> >
> > Doing this breaks the one-to-one relationship between the face's
> > attributes and its appearance.
> 
> But there's only a one-to-one relationship if the face is fully
> specified --- this patch doesn't change that.

That's not true AFAIK, considering the face in isolation.  (I said
that I was abstracting from complications of face merging and
interactions with other display properties.)

> > Consider a Lisp function that helps you customize the foreground
> > and background colors of an individual face.  What it checks and
> > what it produces should reflect the face appearance (again, in
> > isolation).
> >
> > Consider a function that lets you modify the foreground of a given
> > face incrementally, showing you the effect, WYSIWYG-style, in your
> > buffer of C code or whatever.  Maybe it increments hue or
> > saturation or the blue component.  With your feature, what you see
> > by its changing attribute `foreground' will presumably "jump" when
> > the :contrast-function decides that the new value would be too close
> > to the background.
> 
> Yes, that's what would happen, but an editor of this sort --- and
> I'm not aware of any that currently exist

Doesn't matter whether (a) you are aware of that or (b) whether any
actually do exist currently.  The point is that any Lisp code like
that will likely have its life complicated, and so will users of such
code.

Oh, and yes, in fact there are "editors of this sort".  Both DoReMi
and Icicles have commands and other functions that do this kind of
thing.  They give you WYSIWYG incremental tweaking of face attributes.

> --- can just explicitly turn off the adjustment, 

Just don't turn it on by default.  Let users opt in, if they want.

Commands like those I described should probably *not* turn this
off - not without user say-so.  If it is on because the user wants
it on then the commands should show what the real effect of
incrementing various attribute is - WYSIWYG, even if that means
passing through discontinuous jumps (there are already some
discontinuities in the hue model, BTW).  The commands should not
show you a false result, which will then be overridden by The
Twiddler as soon as the user has chosen the look she wants.

> We should optimize emacs as a text editor, not a precise color
> picker or a floor wax. :-)

Dunno what that means.  It's not either/or: text editor or color
picker.  If you are proposing to fiddle with Emacs's choosing
colors, _especially_ if done automatically in an opaque manner
for the user, then you should take seriously such color picking.

I thought this feature was being argued for because it supposedly
provides more reasonable color picking - getting a better
foreground color in some platform-specific, corner cases.  If you
now make fun of "precise color picking" then I have even less
confidence in this whole proposed ball of wax. ;-)