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, tumashu <at> 163.com
Subject: bug#45620: 28.0.50; Child frames should have their own border width and colour
Date: Tue, 5 Jan 2021 13:50:51 +0100
[Message part 1 (text/plain, inline)]
>>> 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 ...

To be honest I've don't really like C as a language, and learning it
would not do anything professionally for me either. So I'm jumping into
this strictly for the sake of improving Emacs.

>> 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));

x, ns and w32 all used the same code, so I changed them all to look like
this now.

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

That's done now too, at least for X. I'll attach patches of my first
working drafts for both changes. Let me know if I'm on the right path so
far.

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

Ok, what do I do?

[0001-WIP-child-frame-border.patch (text/x-patch, attachment)]
[0002-WIP-child-frame-border-width.patch (text/x-patch, attachment)]

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.