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: Mon, 4 Jan 2021 19:54:22 +0100 Message-ID: <000f7dc3-8d6a-a1ba-3f63-b5dd33bb10d6@gmx.at> References: <35f3b179-5e1f-e327-d909-6d934092b01d@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="20783"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45620@debbugs.gnu.org, Feng Shu To: Alexander Miller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 04 19:55:12 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 1kwV0Z-0005Hf-TY for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Jan 2021 19:55:12 +0100 Original-Received: from localhost ([::1]:60554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwV0Y-0002c3-VW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Jan 2021 13:55:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwV0Q-0002be-LO for bug-gnu-emacs@gnu.org; Mon, 04 Jan 2021 13:55:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48746) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kwV0Q-0000iv-EB for bug-gnu-emacs@gnu.org; Mon, 04 Jan 2021 13:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kwV0Q-0006Tu-CK for bug-gnu-emacs@gnu.org; Mon, 04 Jan 2021 13:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Jan 2021 18:55:02 +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.160978647624865 (code B ref 45620); Mon, 04 Jan 2021 18:55:02 +0000 Original-Received: (at 45620) by debbugs.gnu.org; 4 Jan 2021 18:54:36 +0000 Original-Received: from localhost ([127.0.0.1]:60289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kwUzz-0006Sz-Ov for submit@debbugs.gnu.org; Mon, 04 Jan 2021 13:54:36 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:45605) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kwUzx-0006Sl-Vh for 45620@debbugs.gnu.org; Mon, 04 Jan 2021 13:54:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609786464; bh=LNktjEmdQC/GXuSovlnb7vJc9r51ot4yJlymzgQNxfw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=SOZgiImiebPZtLmof0GwK6i8mq0GWsyfgHT6mdNjnqBPc2bNFoVnKU87py9IIiie4 OsqunNgU82fLGTdeDLURNUeNvz7hsQ9I46Ft8s9V0Wi8zvZh2L1dYq8wIrOR/g9sWT zjgyIDyAPFpce3ORqWU0Y+ADlnTmzXYJDrtMHcf8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([46.125.249.15]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvK4f-1k5Uu11RI1-00rGyJ; Mon, 04 Jan 2021 19:54:24 +0100 In-Reply-To: <35f3b179-5e1f-e327-d909-6d934092b01d@web.de> Content-Language: en-US X-Provags-ID: V03:K1:lg0U5VcMrkEh+QVNbCqYyFb5jXaFFqItV+AnnqsGbSkJ656+9rL pZdu3d/XRJtWG7wL3QKrlOsB/aXdOZeIWbvLWHo9LnRO8RTWHBCrTyWFKNbfSSanTChBwyj 3gf/flsfFb12nV/5nXEOL9iRHEKD3LLXi6OBB0AFEZEJcmmvKyj8cbtV/gXtb8XNihtHBUK Z4XfRmYFuOeuMoV4k6cIg== X-UI-Out-Filterresults: notjunk:1;V03:K0:SdUm01RjIUQ=:J5nVBFi2xa0MpNVpnEF20A i9mW/x6S+wmXtVHsClXkERDxpeqY3VrHAwevKNntrcIpbaRi7lt3kpYOTM/xJg1atSoMhkxyw 9FBCTDAdAvdFmdi0kWkuMdttwd10qwoPjbLcuKhbvqCH7asifbKalkJZBpxydPo6wVS6jdUoF 9Jx2nVzX6dLzgXotCzNJ0DaN38InHoMkYEpMEhf5+EVRp567wK5WM3DfRVgacyTQWcl3DjX/h Kuw6s0YLRaHszrps+B8aq3lThGrdj//rVWM8b17aDaddWplZ3a7Tww53OcL0Jwobk2/p/IO1L tg0wKLbVBW18nYuz4XEo+75xtr6eN7FKOrLCxPzd1QwosVABR9t8Y4bpPOijM0Jp2dFbjiZoN rDYCtbX1R1HuNRm2uQmCN8yCxgkHrHywIu7GxEYK2DtGi7VdTw5396IpJLg81g+iJLGf2AP9W KgN7tremN2BbMnj30VcDtFMzB63rIo8M5DQzz+9V9ckCWrQnS8tyPqtLyPs0avBhK35nDkmwN QVf+jkCkEFCFf3iigRNW832fXII1+AOodmg3R9BWr0vbJtBDisuXyohLXC+Uo/H9nP6+UT6Ot mTfZwp7dcfFeiOyb83WKK+uEy+T15ZqtqTZogCJ70wrPVdpj7W17VbFoIoQX5ja5GuZscks7J 6IGQWKJIF+VFZ76c95rZIcN1cCSbogB9SSiVFLRJYGrdSXRz0ZqKrrPOCvl6xStHU16j0CsdW Oxax4Np67iLJwS+T2GIIcOsV8cQuSEb4oPpDkju7FaZmikgOose2IZELWDJ1zuizOiMdgNub 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:197329 Archived-At: > > Can you propose a patch? > > I can *try*. I am absolutely not a C programmer, but as long as the task > is limited to a monkey see, monkey do situation for handling a new face > I should be able to hammer something useful together. That's one way to become a C programmer ... > In fact my first attempt seems to compile and behave as expected, so I > have a few questions on how to proceed: > > - I need to repeatedly use a pattern that looks like this: > > int is_child_frame = FRAME_PARENT_FRAME(f) != NULL; In that case you should make is_child_frame a bool and not an int. But it's much simpler to just test for FRAME_PARENT_FRAME (f) wherever you see a need for is_child_frame like in > int border_face_id = is_child_frame int border_face_id = FRAME_PARENT_FRAME (f) > ? CHILD_FRAME_BORDER_FACE_ID > : INTERNAL_BORDER_FACE_ID; > int face_id = !NILP (Vface_remapping_alist) > ? lookup_basic_face (NULL, f, border_face_id) > : border_face_id; > > and I would like to put it into a single function accessible from > anywhere. Is that the right call, and if yes, where would be the right > place to put it? This is the first time I see the internal border face getting remapped. I wasn't aware that nsterm.c does that and I'm not sure whether we should add something similar to xterm.c and w32term.c. In nsterm.c I would not write an extra function but instead of what we have now use int face_id = (FRAME_PARENT_FRAME (f) ? (!NILP (Vface_remapping_alist) ? lookup_basic_face (NULL, f, CHILD_FRAME_BORDER_FACE_ID) : CHILD_FRAME_BORDER_FACE_ID) : (!NILP (Vface_remapping_alist) ? lookup_basic_face (NULL, f, INTERNAL_BORDER_FACE_ID) : INTERNAL_BORDER_FACE_ID)); and in lookup_basic_face in xfaces.c you'd then have to add case CHILD_FRAME_BORDER_FACE_ID: name = Qchild_frame_border; break; It's augmenting forms like that last one that get the most obscure bugs, so don't despair. > - Currently the actual width of the border is still controlled by the > `internal-border-width` parameter for both frame types. Should I try to > do something about that as well? If yes, what's my entry point? Add a 'child-frame-border-width' parameter. But in this case I would propose to proceed as follows: - If for a frame the 'child-frame-border-width' was explicitly set, use it. - If it was not set, use the 'internal-border-width' parameter. Note that people have already set up their own child frame creation routines and we should try to not punish them too much. And please try to discuss this on the list you cited earlier and also with the posframe.el designer. Mister Feng Shu you've inevitably become a participant of this thread now. > - I think I'll need to sign the FSF copyright assignment, unless the > limit is higher than the 15 lines I am remembering. I think so too. martin