GNU bug report logs - #46184
28.0.50; child-frame-border-width of 0 falls back to internla-border-width

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Sat, 30 Jan 2021 05:53:01 UTC

Severity: normal

Tags: fixed

Found in version 28.0.50

Fixed in version 28.1

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Alexander Miller <alexanderm <at> web.de>
Cc: 46184 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: Re: bug#46184: 28.0.50; child-frame-border-width of 0 falls back to
 internla-border-width
Date: Thu, 4 Feb 2021 09:40:10 +0100
> I have tried the patch and the case for using 0 does work without
> fallback now.
>
> I also tried setting an explicit `nil` value and got an error, but
> judging by how `internal-border-width` shows the same behaviour I assume
> that it's working as expected.

Indeed.  That's why I dislike frame parameters.  WOW users cannot set
'internal-border-width' back to its initial value once it changed.  For
scroll bars we use a two-tiers approach where users can tweak width and
type separately.  Doing something similar for the internal border seems
a bit excessive to me.

Though, I am currently investigating doing something similar for tooltip
frames.  IIRC it was you who also noticed that the border we currently
draw around them is only on top and the left.  I meanwhile found out
that this is due to us trying to use the 'border-width' of the frame (a
completely obscure X concept) for that purpose.  If I can't fix that
(and it would be an X-only fix anyway) I'll try to replace it with our
own internal border, but I'm not sure whether I succeed.

Currently, the internal border face, once customized, shows through in
our tooltips only after some delay which is quite irritating.  Also, I
still don't know whether we want the internal border of tooltip frames
as a means (1) to "set off" text from the rest of the screen by splicing
in some space in the background face, or (2) to "separate" text from the
rest of the screen by splicing in space in a face that differs from the
background.  Currently, we can't have both.  We'd have to brush up the
internal borders in way similar to window dividers.

Thanks for checking, martin




This bug report was last modified 3 years and 364 days ago.

Previous Next


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