unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Alexander Miller <alexanderm@web.de>
Cc: 45620@debbugs.gnu.org, Feng Shu <tumashu@163.com>
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	[thread overview]
Message-ID: <000f7dc3-8d6a-a1ba-3f63-b5dd33bb10d6@gmx.at> (raw)
In-Reply-To: <35f3b179-5e1f-e327-d909-6d934092b01d@web.de>

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





  reply	other threads:[~2021-01-04 18:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-03 13:24 bug#45620: 28.0.50; Child frames should have their own border width and colour Alexander Miller
2021-01-03 16:15 ` martin rudalics
2021-01-04 13:38 ` Alexander Miller
2021-01-04 16:22   ` martin rudalics
2021-01-04 17:48 ` Alexander Miller
2021-01-04 18:54   ` martin rudalics [this message]
2021-01-05 12:50 ` Alexander Miller
2021-01-05 15:33   ` martin rudalics
2021-01-05 15:34     ` martin rudalics
2021-01-06 11:32       ` Arthur Miller
2021-01-06 13:36         ` martin rudalics
2021-01-06 15:01           ` Arthur Miller
2021-01-05 16:26     ` Eli Zaretskii
2021-01-06 16:32 ` Alexander Miller
2021-01-06 18:48   ` martin rudalics
2021-01-13  9:17 ` Alexander Miller
2021-01-13 18:07   ` martin rudalics
2021-01-25 12:08 ` Alexander Miller
2021-01-25 19:05   ` martin rudalics
2021-01-26 15:59     ` martin rudalics
2021-01-27 20:49       ` Alan Third
2021-01-28  9:42         ` martin rudalics
2021-01-28 16:35           ` Alan Third
2021-01-29  7:51             ` martin rudalics
2021-01-27 20:44 ` Alexander Miller
2021-01-28  3:33   ` Eli Zaretskii
2021-01-28  7:06 ` Alexander Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=000f7dc3-8d6a-a1ba-3f63-b5dd33bb10d6@gmx.at \
    --to=rudalics@gmx.at \
    --cc=45620@debbugs.gnu.org \
    --cc=alexanderm@web.de \
    --cc=tumashu@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).