GNU bug report logs - #40639
26.3; Child frame border color not rendered when child frame has no minibuffer

Previous Next

Full log

Message #11 received at 40639 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: alexanderm <at> web.de, 40639 <at> debbugs.gnu.org
Subject: Re: bug#40639: 26.3;
 Child frame border color not rendered when child frame has no
 minibuffer
Date: Wed, 15 Apr 2020 20:32:33 +0300

> From: martin rudalics <rudalics <at> gmx.at>
> Date: Wed, 15 Apr 2020 19:20:45 +0200
> 
>        int face_id =
> 	!NILP (Vface_remapping_alist)
> 	? lookup_basic_face (NULL, f, INTERNAL_BORDER_FACE_ID)
> 	: INTERNAL_BORDER_FACE_ID;
>        struct face *face = FACE_FROM_ID_OR_NULL (f, face_id);
> 
>        block_input ();
> 
>        if (face)
> 	{
> 	  unsigned long color = face->background;
> 
> the value of color for a new normal frame is for a few calls white but
> switches to red before the frame appears on the display.  A child frame
> usually must be explicitly focused before its border becomes red (I
> don't necessarily need the mouse for that purpose, C-x 5 o works too).
> 
> Maybe our experts in face remapping have an idea.

I don't think face mapping is directly involved, this sounds like some
X event causes the change.

Previous Next

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