emacs-devel
[Top][All Lists]
Advanced

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

Re: "Why is emacs so square?"


From: Clément Pit-Claudel
Subject: Re: "Why is emacs so square?"
Date: Fri, 17 Apr 2020 11:52:56 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 17/04/2020 11.38, Eli Zaretskii wrote:
>> Cc: address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Fri, 17 Apr 2020 11:27:56 -0400
>>
>>> I don't know.  AFAIK, we don't have infrastructure for deciding when
>>> stuff like that needs to be re-evaluated and how to use different
>>> results for different frames.  If someone wants to work on such
>>> infrastructure, I think it will bring us a step closer to being able
>>> to support different GUI frame types (like GTK, w32, NS, etc.) in the
>>> same session.
>>
>> I may be missing something, but I don't think such infrastructure is needed 
>> here — we already have most of what's needed with conditional faces.
> 
> Faces were always per-frame (although when you customize a face, it
> changes on all frames), but faces are just the tip of the iceberg.
> The general problem with GUI features is much wider.  I thought you
> were talking about the more general problem.

I'm talking only about the OP's problem, which was that buttons were not 
displayed in 3D.

>> The attached patch gets us 90% of the way, with the only remaining issue 
>> being wrapping buttons in square brackets on text terminals.
>>
>>  (defface custom-button-pressed
>>    '((((type x w32 ns) (class color))
>>       :box (:line-width 2 :style pressed-button)
>>       :background "lightgrey" :foreground "black")
>> -    (t :inverse-video t))
>> +    (t :inherit custom-button-pressed-unraised))
>>    "Face for pressed custom buttons if `custom-raised-buttons' is non-nil."
>>    :version "21.1"
>>    :group 'custom-faces)
> 
> Why a separate face, instead of a separate definition of the same face
> for non-GUI displays?

To be able to honor the custom-raised-buttons setting.  I wouldn't design it 
that way, but that's where we are.

> Anyway, the condition should not be on frame types, but rather on
> capabilities, IMO.

Agreed.
Do you know how the problem with square brackets could be solved?  Currently 
the custom-raised-buttons setting is used to chose a face and to decide whether 
to insert square brackets around buttons. Is there a clean way to make these 
brackets display only in text terminals?



reply via email to

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