GNU bug report logs - #66247
29.1; Transient frame problems with Emacs 29 on MS Windows

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: luangruo <at> yahoo.com, 66247 <at> debbugs.gnu.org
Subject: bug#66247: 29.1; Transient frame problems with Emacs 29 on MS Windows
Date: Mon, 09 Oct 2023 21:56:03 +0300

> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "luangruo <at> yahoo.com" <luangruo <at> yahoo.com>,
>         "66247 <at> debbugs.gnu.org"
> 	<66247 <at> debbugs.gnu.org>
> Date: Mon, 9 Oct 2023 18:33:48 +0000
> 
> In addition to the problems described, even when
> parameter `inhibit-double-buffering' is `t':
> 
> When applying a set of frame position and size
> modifications, the transient appearance shows
> not only the scroll bar in the initial position
> but the overall frame, even after it's resized,
> remains in the original position.  The final
> position and location of the scroll bar are not
> realized at the same time as the frame is resized.
> 
> There is a _general_ regression wrt the behavior
> in all previous Emacs releases (back through 20,
> at least).  Setting `inhibit-double-buffering' to
> `t' removes only some of the problems introduced.
> 
> You may say that the rest of the frame-display
> implementation, besides the addition of double
> buffering, wasn't changed for Emacs 29, but that
> doesn't seem to be the case.  Something has led
> to a regression wrt frame display - multiple
> frame parameters.

Needless to say, I see none of this on my system.  But since you
didn't post any information regarding how to reproduce this, not even
which commands and/or functions are used when this happens, it is hard
to tell whether it simply doesn't happen here or you do something that
I don't.

> When a set of parameters are changed with one
> `modify-frame-parameters' the effect is not to
> change them all at once - and that's new (a
> regression).  The frame is resized, and some
> time later the other frame modifications take
> effect.

Frame parameters were always applied one by one in Emacs, not
together.  This is not a regression, this is how Emacs always worked.

Bottom line: I find such "bug reports" extremely frustrating, because
nothing, literally nothing, can be done about them without extra
details.

Previous Next

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