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

Previous Next

Full log

Message #60 received at 66247-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: luangruo <at> yahoo.com, 66247-done <at> debbugs.gnu.org
Subject: Re: [External] : bug#66247: 29.1; Transient frame problems with Emacs
 29 on MS Windows
Date: Tue, 10 Oct 2023 21:46:52 +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: Tue, 10 Oct 2023 15:53:56 +0000
> 
> > > BTW, what's the rationale behind making this
> > > a frame parameter rather than just an option
> > > that affects all frames?  Presumably there is
> > > some use case for having it ON or OFF for only
> > > specific frames or groups of frames.  I'm
> > > curious what such a use case might be.
> > 
> > This comes from Unix, where each frame can be on a different X
> > display, and therefore could use a different display driver.
> 
> Aha!  Now it makes sense to me (it's been a long
> time since I used X Window).
> 
> I wonder whether it might make sense for the doc
> to say something about this?
> 
> Maybe more importantly I wonder whether it might
> make sense to add a user option that has the
> effect of turning on/off double-buffering for
> all frames.

We already have that, for every frame-parameter: customize both
initial-frame-alist and default-frame-alist.  Why do we need something
else, and why should this particular parameter be different from all
the other frame parameters?

> Do you think it would be good to add an option?

No, I think it would be a needless complication.

> Anyway, this is OT for this bug, which can be
> closed, IMO.

Done.

Previous Next

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