From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#45620: 28.0.50; Child frames should have their own border width and colour Date: Sun, 3 Jan 2021 17:15:58 +0100 Message-ID: <43ccff46-1d67-2300-7098-b419966dfd66@gmx.at> References: <30630458-2ef4-7da9-ea28-cdb12052dba2@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13198"; mail-complaints-to="usenet@ciao.gmane.io" To: Alexander Miller , 45620@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 03 17:17:23 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kw64I-0003LA-PQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Jan 2021 17:17:22 +0100 Original-Received: from localhost ([::1]:46484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kw64H-0003eZ-Q2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Jan 2021 11:17:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35196) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kw63y-0003dQ-19 for bug-gnu-emacs@gnu.org; Sun, 03 Jan 2021 11:17:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55137) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kw63x-0000NS-QN for bug-gnu-emacs@gnu.org; Sun, 03 Jan 2021 11:17:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kw63x-0005lB-MT for bug-gnu-emacs@gnu.org; Sun, 03 Jan 2021 11:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Jan 2021 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45620 X-GNU-PR-Package: emacs Original-Received: via spool by 45620-submit@debbugs.gnu.org id=B45620.160969057122078 (code B ref 45620); Sun, 03 Jan 2021 16:17:01 +0000 Original-Received: (at 45620) by debbugs.gnu.org; 3 Jan 2021 16:16:11 +0000 Original-Received: from localhost ([127.0.0.1]:38450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kw638-0005k2-Ta for submit@debbugs.gnu.org; Sun, 03 Jan 2021 11:16:11 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:40523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kw634-0005jG-4y for 45620@debbugs.gnu.org; Sun, 03 Jan 2021 11:16:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609690559; bh=+K3N7ZRKe8mY+dHybf4e97W+xu/cykxKVjBKV9D6bzk=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=SUeWeW0OFdtN58zXSoQkp6GqSElboGhl3XXYNHJVFxe+TSMWjCRlyJPhNbFxXjRiQ OUKRuFEaF8e31Lc5eI3jM6yJbnU+MiSc5xc7iRCmr+s69SygXey6ZdN9bbvrEn6XQy 4Tz5ktodKet6NfT2718WVw6bFMFTIfWe29ajvcfA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.103] ([212.95.5.250]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MhU5R-1kIece30F9-00eaxx; Sun, 03 Jan 2021 17:15:59 +0100 In-Reply-To: <30630458-2ef4-7da9-ea28-cdb12052dba2@web.de> Content-Language: en-US X-Provags-ID: V03:K1:UuzUO+Wrh1/qx5TvdqA8U5IFGhWZZK1w23hCyhIJzKCbmciIMzf bnuCY9xvRku/s+75+qfcOpN/BpX8us6Xn6NNUgh2ycTUrbAbpNDxrTLgwirc2cqrxipkBcx DKesSjR8bei/i3ZmzEcnfyTdk5/rJtVji8WGtXmPQ+HydHcT1UhcqLVZJv9ocDaHh8lTsX+ CrHO7m4kkA0wYh4uRIMHw== X-UI-Out-Filterresults: notjunk:1;V03:K0:DR6xLBF69oc=:ziTPKPY6WbfR4jRuREJ2VL RNyfq8dx0TFFgFdjk/DB52omgy9VaYUNeIuy9ne4cpwV48rXtF67bQ+BoTm2J/g4RVoQeTCfQ wH9ERSXOef7c8UqX5VDX3Zqs+ds1jlfxXeJzoPqB95hT64exPMvnURR/GK0yv3X3iNNCuC/dz UOvDgSWfeFfdab3ZXezhGOke333+4Nbs7EmX8uyw+u4pibtJHLBDsQy36yEXg6hrClVI7ntjC bXOug2r872bqLqH+JQCfDA6eZEzX850Ny4NnHdUHVUnGQeMoKlQ+PA+u7vrAlvej/38ZYzYPI zMNOE0IoEo4KByB3Yj4HXXnIgPlcu/vx8iwoJlUu5R/CYsRDNq5fL8l5nC7+0kNQzwhvFbp9x 0DnY3PxgMhBjxE91yRXXwapsJD1E8zaj9/qitG1N2F6P0cpkQMQAIUb9sJI3zs6o7fLNDiT7n pRHvCGTA/+RKlmAQfY4o/0CclNZZQLfiB/MmAV8dYPywH+tVhvwjAZ0zyUnlHFUz2WuppJRIR faoOZArL1B0fSH20jd82XTybDuvmeWzngcOkX0Y1uSWNI6yWVSFkyADTUHr5BeWGbLXkFOlR0 tPWNPvw4KsMaKAOOj81kzOlZGVMff7nfuHLcBYjKXf/6OBtPI+kIrzJ4Tsn329EjxGXYImehp D3QcSmvlQbTuMzoUiIWMwCydVrBKNl5j3qMUvcaKA95Z7bPwKAzENkM1VSxYNJtAiw5iq8PCO /1Xo73Q1nzZ3R26wwsc1DxHMFudOXg28Azk5IZfDh7EB/Dj/fPKu2o60eKkT4x3rTIjgU4vU X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:197253 Archived-At: > This is an idea set off by this discussion: > https://github.com/Alexander-Miller/treemacs/issues/242#issuecomment-753296634 > > Basically the problem is that child frames need a distinct border colour > to be properly visible (and just using a different background colour does > not look nearly as good). > > That can be achieved by customising the `internal-border' face, however > that face controls the appearance of the border of all frames, and as I > have learned there is a non-trivial amount of users who by default use a > large internal border as a margin for their frames. And for these users > the `internal-border' should have the same colour as the default > background. 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. > So there is a conflict between wanting a distinct border colour for > child frames and using the default background for normal frames. If I'm not mistaken we use that face for our tooltip frames too which means one more conflict. > Packages can work around that individually, for example posframe accepts > an `internal-border-color' argument that overrides the `internal-border' > face frame-locally. But that still means that every package using child > frames needs its own user option for the child frames' border colour > when such matters clearly belong under the domain of the user's theme. "clearly" is clearly too strong here. Ultimately, the package must have the choice and its choice should prevail (it currently doesn't). > I think that since child frames serve sufficiently distinct use cases > than normal frames it makes sense for them to have their own border > appearance controls. So what should we do? Provide a separate 'child-frame-internal-border' face and then probably also a 'tooltip-internal-border-face'? Customizing such a face would still override individual frame settings. What we need is probably a strategy to avoid setting the background for those frames that have their internal border already set. But then we should do that for all faces running through 'set-face-attribute'. martin