GNU bug report logs - #76275
31.0.50; frame-inhibit-implied-resize broken on recent master

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com, spwhitton <at> spwhitton.name
Subject: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent
 master
Date: Fri, 28 Feb 2025 13:47:02 +0200

> Date: Fri, 28 Feb 2025 10:25:07 +0100
> Cc: spwhitton <at> spwhitton.name, 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Maybe we should instead explain which settings could cause resize with
>  > t, but not with 'force'?
> 
> Here with a GTK3 build I get the following (frame-pixel-height) /
> (frame-total-lines) values:
> 
> emacs -Q ~> 792 / 36
> 
> emacs -Q --eval "(setopt frame-inhibit-implied-resize t)" ~> 751 / 34
> 
> emacs -Q --eval "(setopt frame-inhibit-implied-resize 'force)" ~> 751 / 34
> 
> So with a GTK build here the major difference is between nil and t and
> there's no difference between t and 'force.  Yet Sean sees a difference
> with t and 'force.
> 
> And with a Lucid build I get 830 / 37 in all cases.  What can I possibly
> explain?  Can you see a difference with these three cases?

If you understand why Sean sees a difference, please tell why, and I
will try to see how to document that.

Is the GTK case the only one you know of when these two settings yield
different effects?

Thanks.

Previous Next

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