GNU bug report logs - #45620
28.0.50; Child frames should have their own border width and colour

Previous Next

Package: emacs;

Reported by: Alexander Miller <alexanderm <at> web.de>

Date: Sun, 3 Jan 2021 13:19:01 UTC

Severity: normal

Found in version 28.0.50

Done: Alexander Miller <alexanderm <at> web.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alexander Miller <alexanderm <at> web.de>
To: rudalics <at> gmx.at
Cc: 45620 <at> debbugs.gnu.org
Subject: bug#45620: 28.0.50; Child frames should have their own border width and colour
Date: Mon, 4 Jan 2021 14:38:37 +0100
> Isn't the situation even worse than how you describe it here? When I
> customize 'internal-border' face, that affects all frames, including
> those for which I have set it already via 'set-face-background'. Which
> means that whatever a package does to set that face for a specific
> (child) frame, that setting is undone by a later customization. IIUC
> the discussion you refer to above arrived at the same conclusion.

What customisations are you referring to? I cannot think of any
scenario, other than changing and reloading your theme, that could
change the settings of already present child frames.

> If I'm not mistaken we use that face for our tooltip frames too which
> means one more conflict.

Partially. On my system the internal-border colour and width only
applied to the top and left sides of the tooltip frame.

> "clearly" is clearly too strong here. Ultimately, the package must have
> the choice and its choice should prevail (it currently doesn't).

Packages do have the choice, they just have to make sure to override the
frame-local faces whenever they show something. The problem, as I see
it, is that they *have to* create a face to override the local
internal-border, instead of just having the option to do it, because
themes cannot offer a general setting, like an easily visible dark
border on a bright foreground, because they run into the frame margin
colour conflict like modus did in the linked issue. So if a package
doesn't overwrite the local internal-border your default look-and-feel
is a badly visible same-colour-on-same-colour popup.

> So what should we do? Provide a separate 'child-frame-internal-border'
> face and then probably also a 'tooltip-internal-border-face'?

That would be perfectly good enough for themes like modus, yes.





This bug report was last modified 4 years and 175 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.