emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About the :distant-foreground face attribute


From: Jan Djärv
Subject: Re: About the :distant-foreground face attribute
Date: Sun, 12 Jan 2014 23:07:39 +0100

Hello.

12 jan 2014 kl. 21:14 skrev Chong Yidong <address@hidden>:

> Instead, here's a compromise proposal:
> 
> - Allow :foreground to take the value of (fallback COLOR) or something
>  like that, which would be equivalent to setting :foreground to
>  unspecified and :distant-foreground to COLOR.
> 
>  (We still need a replacement term for "distant foreground".  As
>  mentioned before, this term sounds nonsensical.)
> 

There is a function called distant_color in the source, thats where it comes 
from.

> - In order to avoid incompatibilities, set the :foreground of the
>  `region' face to "*_selection_fg_color".  In other words, avoid using
>  the above feature in the `region' face, at least for Emacs 24.4.
> 
>  The rationale is that (i) we can live with having a fixed foreground
>  color for the `region' face, since that was the case in Emacs 24.3 on
>  GTK anyway.  And (ii) not using this feature immediately gives
>  third-party packages a "transition period" to adapt to its presence,
>  without immediately failing by encountering it in a standard face.
> 
> If there are no objections, I can implement this.

Count this as an objection. (i) means reopening a fixed bug BTW, don't forget 
that.
I don't think this should be done at all, but lets just consider 24.4:

1) We are talking about a replacing a feature that has no outstanding bugs, and 
has been in place for about 2 months.
2) The only reason too replace it is some personal feelings about "clean 
design", based on unknown principles, that are not documented in any Emacs or 
GNU document.
3) The code for this proposal will be messier.  Distant-foreground is quite 
separate in the code, you can easily find any place where the source handles to 
it.  This proposal suggests modifying foreground, thus changing a lot of places 
where foreground are handeled.  Not only is this bound to introduce bugs, but 
the feature is not as easily seen in the source.

And all this during a feature freeze?  It makes feature freeze kind of 
pointless if any feature can be replaced willy nilly based on a persons design 
feelings.

But this is Stefans call.

        Jan D.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]