On Tue, 10 Sept 2024 at 18:16, martin rudalics wrote:
> > Can I just check: do you want me to apply your latest gtkutil-reject.diff
> > on top of your previous size_hints.diff, or instead of it?
>
> Instead of it.
>
Here is the frame size history:
Frame size history of #
x_create_frame_1 (5), T
Can I just check: do you want me to apply your latest gtkutil-reject.diff
on top of your previous size_hints.diff, or instead of it?
Instead of it.
martin
On Tue, 10 Sept 2024 at 10:32, martin rudalics wrote:
>
> Since you run with
>
> emacs -Q --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"
>
> Emacs considers menu bars to be currently enabled "globally" and
> disabling them globally has no effect on that frame. Do you agree with
> t
>> What does (frame-text-height) return for the first and the
>> second frame?
>
> 1260 for both.
Relieving.
>>Also I hope you didn't get the GTK assertion failure.
>>
>
> Indeed, I do not.
So the sequence definitely is: For some inexplicable reason we receive a
ConfigureNotify event that t
I've removed the patch to frame.c, and I'm running with:
emacs -Q --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"
On Mon, 9 Sept 2024 at 17:52, martin rudalics wrote:
>
> The result is not yet what I hoped for. We reject two ConfigureNotify
> events but the ensuing xg_frame_set_ch
> This makes an obviously visible difference: C-x 5 2 opens a small frame
> which immediately becomes large.
>
> Here's the *frame-size-history* buffer:
...
> ConfigureNotify, PS=1328x1260, XS=400x374, DS=1328x1260
> xg_frame_resized, rejected, PS=1328x1260, XS=400x374, DS=664x630
> tool-bar-lines
On Mon, 9 Sept 2024 at 13:33, martin rudalics wrote:
> Obviously. I modified the PGTK part. Please try again with what I
> attached now.
>
This makes an obviously visible difference: C-x 5 2 opens a small frame
which immediately becomes large.
Here's the *frame-size-history* buffer:
Frame si
> Thanks for your persistence, Martin!
Thanks for yours!
> (No infinite loop!)
Obviously. I modified the PGTK part. Please try again with what I
attached now.
martindiff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..89061245500 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -11
Thanks for your persistence, Martin!
On Mon, 9 Sept 2024 at 09:58, martin rudalics wrote:
>
> I forgot whether creating an initial frame without menubar works
> reasonably on your system. So please do the same once more but this
> time with --eval "(setq default-frame-alist '((menu-bar-lines .
The important fact is that in the entire sequence of the initial frame's
setup you never experience one of those strange ConfigureNotify events
asking to shrink the frame. Why they happen only for subsequent frame
creations will probably remain a mystery.
A new mystery is that your creation of t
On Sun, 8 Sept 2024 at 17:54, martin rudalics wrote:
> > If not, then we should try to understand why not. Please with pristine
> >> master replace the initial assignment of 'frame-size-history' in
> frame.c
> >> from
> >>
> >> frame_size_history = Qnil;
> >>
> >> to
> >>
> >> f
> If not, then we should try to understand why not. Please with pristine
>> master replace the initial assignment of 'frame-size-history' in frame.c
>> from
>>
>> frame_size_history = Qnil;
>>
>> to
>>
>> frame_size_history = Fcons (make_fixnum (100), Qnil);
>>
>> start Emacs -Q and tell
On Sun, 8 Sept 2024 at 15:21, martin rudalics wrote:
> >>
> >> Do you get an assertion failure already before the C-x 5 2?
> >
> > No.
>
> Thanks. Did you ever get an assertion failure for the original frame?
>
I don't think so, no.
If not, then we should try to understand why not. Please
>> >> -#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
>> >> +#if defined (USE_X_TOOLKIT) && !defined (USE_GTK)
>> >>
>> >
>> > OK, so I applied this patch and ran `emacs -Q`, then did C-x 5 2 and got
>> > the usual small window and error:
>> >
>> > (emacs:3159980): Gtk-CRITICAL *
On Sun, 8 Sept 2024 at 09:42, martin rudalics wrote:
> >> -#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
> >> +#if defined (USE_X_TOOLKIT) && !defined (USE_GTK)
> >>
> >
> > OK, so I applied this patch and ran `emacs -Q`, then did C-x 5 2 and got
> > the usual small window and error:
>
>> -#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
>> +#if defined (USE_X_TOOLKIT) && !defined (USE_GTK)
>>
>
> OK, so I applied this patch and ran `emacs -Q`, then did C-x 5 2 and got
> the usual small window and error:
>
> (emacs:3159980): Gtk-CRITICAL **: 13:05:49.056:
> gtk_distribute_natura
On Sat, 7 Sept 2024 at 09:37, martin rudalics wrote:
>
> -#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
> +#if defined (USE_X_TOOLKIT) && !defined (USE_GTK)
>
OK, so I applied this patch and ran `emacs -Q`, then did C-x 5 2 and got
the usual small window and error:
(emacs:3159980): Gtk-CRITI
> I then applied the trivial patch you gave to git master HEAD, ran 'emacs
> -Q' and did C-x 5 2, and got a small window as usual, but with no error
> message in the terminal.
Let's try to continue from here. Instead of the "trivial" patch please
now use
diff --git a/src/xfns.c b/src/xfns.c
ind
On Fri, 6 Sept 2024 at 15:16, martin rudalics wrote:
>
> OK. In the next step I'd like to isolate the menubar code as the sole
> culprit for what's going in. Please with master do
>
> (setq default-frame-alist '((width . 200)))
>
It takes effect on the initial frame, but doesn't affect the siz
> Now the change_frame_size(5) initial and final sizes look correct.
OK. In the next step I'd like to isolate the menubar code as the sole
culprit for what's going in. Please with master do
(setq default-frame-alist '((width . 200)))
or some other insanely large value so we can see whether we
On Fri, 6 Sept 2024 at 10:50, martin rudalics wrote:
> > Buffer contents for master HEAD after C-x 5 2:
>
> I can't figure out what's going on.
I couldn't make sense of the results I sent either, so I re-ran the tests.
Buffer contents after C-x 5 2 with commit 24161683102 reverted:
Frame siz
> Buffer contents for master HEAD after C-x 5 2:
I can't figure out what's going on. We get a
ConfigureNotify, PS=400x374, XS=1280x1354
event that tells us to set the frame to some "reasonable" size at least.
And the penultimate lines
> change_frame_size (5), TS=352x374~>1232x1354, TC=22x10~>
On Fri, 6 Sept 2024 at 08:54, martin rudalics wrote:
>
> Inexplicable to me. Please conduct both runs once more. But rather
> than using the debugger simply evaluate
>
> (setq frame-size-history '(100))
>
> in the initial frame, do C-x 5 2, evaluate
>
> (frame--size-history)
>
> and post the co
> I checked out git master HEAD (currently df57e44a08f) and reverted commit
> 241616831024c9c9fe2b2378b611db0a560b9675 on top of that.
Good.
> and please first run without the commit under
>> gdb with a breakpoint at the line
>>
>> adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
>>
On Thu, 5 Sept 2024 at 08:49, martin rudalics wrote:
> > My bisection suggests the problematic commit is
> > 241616831024c9c9fe2b2378b611db0a560b9675
>
> Thanks. Please try first setting 'frame-inhibit-implied-resize' to t
> which should avoid that a frame gets resized when the menu bar is
> e
> My bisection suggests the problematic commit is
> 241616831024c9c9fe2b2378b611db0a560b9675
Thanks. Please try first setting 'frame-inhibit-implied-resize' to t
which should avoid that a frame gets resized when the menu bar is
enabled or disabled (this time I have slightly more hope that it fix
On Wed, 4 Sept 2024 at 18:11, martin rudalics wrote:
> > Just to check, you're suggesting that I bisect from emacs-29.3 (I use
> that
> > tag because it's what the version of 29 I'm using is built from) to
> master
> > HEAD, to find at which commit C-x 5 2 opens a small window immediately
> >
> Just to check, you're suggesting that I bisect from emacs-29.3 (I use that
> tag because it's what the version of 29 I'm using is built from) to master
> HEAD, to find at which commit C-x 5 2 opens a small window immediately
> (without disabling menu-bar-mode)?
That's the idea, yes.
> This mad
> On Wed, 04 Sep 2024 20:12:28 +0800, Po Lu via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" said:
Po Lu> If it is this bug that you are trying to isolate, we have already
heard
Po Lu> reports of its being reproducible all the way to Emacs 26.1, and
Po
Reuben Thomas writes:
> On Wed, 4 Sept 2024 at 09:02, martin rudalics wrote:
>
> >>
> >> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
> >>
> >
> > Yes, both with Emacs 29 and git master produce this message when
> > menu-bar-mode is non-nil, and the menu bar
On Wed, 4 Sept 2024 at 09:02, martin rudalics wrote:
> >>
> >> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
> >>
> >
> > Yes, both with Emacs 29 and git master produce this message when
> > menu-bar-mode is non-nil, and the menu bar is drawn, in both window
> sizes
> Isn't it true that disabling menu-bar-mode from the init file avoids
> these problems?
In Reuben's second scenario 'menu-bar-mode' is not disabled. The second
frame is smaller with the menu bar enabled.
martin
>> Thanks. The geometry values are consistent with what you described.
>> This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559. When
>> you run Emacs from a console or under gdb can you observe whether it
>> triggers a
>>
>> gtk_distribute_natural_allocation: assertion 'extra_space >=
On Tue, 3 Sept 2024 at 18:44, Eli Zaretskii wrote:
> Isn't it true that disabling menu-bar-mode from the init file avoids
> these problems?
>
I don't think so: I had it customized off and had to bisect my
customizations in order to find what was causing the problem.
Reuben, is running with menu
> Date: Tue, 3 Sep 2024 19:03:05 +0200
> Cc: Eli Zaretskii , Po Lu ,
> 72...@debbugs.gnu.org
> From: martin rudalics
>
> mutter doesn't like us. Just to make sure one thing: Would setting
> 'frame-resize-pixelwise' to t change anything?
>
> Otherwise I would try to build Emacs with gtk2, lucid
On Tue, 3 Sept 2024 at 18:29, Reuben Thomas wrote:
>
> Otherwise I would try to build Emacs with gtk2, lucid or motif.
>
>
>
I can confirm that building with no toolkit (as recommended in the issues
you mentioned) also fixes the problem.
--
https://rrt.sc3d.org
On Tue, 3 Sept 2024 at 18:03, martin rudalics wrote:
> > Sure thing:
>
> Thanks. The geometry values are consistent with what you described.
> This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559. When
> you run Emacs from a console or under gdb can you observe whether it
> triggers
> Sure thing:
Thanks. The geometry values are consistent with what you described.
This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559. When
you run Emacs from a console or under gdb can you observe whether it
triggers a
gtk_distribute_natural_allocation: assertion 'extra_space >= 0
On Tue, 3 Sept 2024 at 16:52, martin rudalics wrote:
> >> Reproduction with Emacs 29.3 (also with git master HEAD, see below).
> >>
> >> Run: emacs -Q
> >> C-x 5 2 ; window opens the same size as the initial window
> >> M-x menu-bar-mode RET ; disable menu-bar-mode
>
> Here with a GTK-3 buil
>> Reproduction with Emacs 29.3 (also with git master HEAD, see below).
>>
>> Run: emacs -Q
>> C-x 5 2 ; window opens the same size as the initial window
>> M-x menu-bar-mode RET ; disable menu-bar-mode
Here with a GTK-3 build on XFCE disabling menu-bar-mode makes both
frames smaller by the menu
On Tue, 3 Sept 2024 at 13:07, Eli Zaretskii wrote:
>
> You didn't say which toolkit did you build with. It might be
> important.
>
gtk-3 in both cases.
--
https://rrt.sc3d.org
> Date: Mon, 2 Sep 2024 19:48:57 +0100
> From: Reuben Thomas via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors"
>
> Reproduction with Emacs 29.3 (also with git master HEAD, see below).
>
> Run: emacs -Q
> C-x 5 2 ; window opens the same size as the initial window
> M-x men
Reproduction with Emacs 29.3 (also with git master HEAD, see below).
Run: emacs -Q
C-x 5 2 ; window opens the same size as the initial window
M-x menu-bar-mode RET ; disable menu-bar-mode
C-x 52 ; window opens much smaller than initial window
With master HEAD (commit 92ea393a16e), the situation i
43 matches
Mail list logo
