Re: "Why is emacs so square?"

[Eli Zaretskii]

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

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

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