GNU bug report logs - #18451
24.4.50; 'toggle-frame-fullscreen' can cut off minibuffer

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Matthew Leach <matthew <at> mattleach.net>
Cc: 18451 <at> debbugs.gnu.org, Jan Djärv <jan.h.d <at> swipnet.se>
Subject: bug#18451: 24.4.50; 'toggle-frame-fullscreen' can cut off minibuffer
Date: Thu, 18 Sep 2014 14:41:34 +0200

>> Just for the record, even if you eval the form when startin Emacs?
>
> Actually, I hadn't done that, I just evaluated it in the scratch buffer.

I would have done that in your place too ;-)

> However, when I paste this as the first form in my .emacs it seems to
> fix the issue! I've been toggling for about 10 minutes now and haven't
> seen an occurrence of the bug.

I'm afraid this issue is not only restricted to your window manager and
not only to getting a fullscreen display.  I've recently observed a
similar problem when trying to always come up with the same frame height
with plain emacs -Q on a Gtk build.  On the average it fails every
fourth time with three missing lines.  It does not fail when I set
`frame-resize-pixelwise' to a non-nil value.

> Oops, configure_frame_size should be `change_frame_size' defined in
> dispnew.c

I should have figured that out.  Where exactly is your trace point?
Personally I prefer one in change_frame_size_1 where it says

      /* This size-change overrides any pending one for this frame.  */

to avoid that a rescheduled change_frame_size appears in the trace but
it certainly doesn't matter here.

>> Are the traces here in chronological order or reversed?
>
> They are in chronological order.

Good (it's not obvious from the trace alone).  Still I miss things like

change_frame_size(0x6896f8, 1350, 768, 0, 1, 0, 1);
ConfigureNotify event received.
ConfigureNotify event received.
change_frame_size(0x6896f8, 1350, 768, 0, 0, 1, 1);
ConfigureNotify event received.
ConfigureNotify event received.
ConfigureNotify event received.
xg_frame_resized(0x6896f8, 679, 729);
change_frame_size(0x6896f8, 663, 729, 0, 1, 0, 1);
change_frame_size(0x6896f8, 663, 729, 0, 0, 0, 1);
ConfigureNotify event received.
ConfigureNotify event received.
xg_frame_resized(0x6896f8, 672, 720);
change_frame_size(0x6896f8, 656, 720, 0, 1, 0, 1);
xg_frame_resized(0x6781b0, 1366, 768);
configure_frame_size(0x6781b0, 1350, 768, 330584, 1, 0, 1);

from your earlier trace where some height change seems visible.

>> And how do you get a ConfigureNotify event for a frame `nil'?
>
> I'm not sure, but it seems to be expected behaviour as there is an
> explicit test for it in the ConfigureNotify event handler.  The frame is
> set to `any' if x_top_window_to_frame returns null.

Arrgh...  I'm too silly.

In any case, the problem could be due to the following:

(1) Due to some non-textual settings (scroll bar, divider, border width)
    we ask the window manager for a frame height which is _not_ an
    integral multiple of the nominal character height.  At the same time
    we ask the window manager to store that nominal height as the
    canonical height by which frame height change increments should be
    allowed.

(2) The window manager (sometimes) decides that our resize request is
    impudent and overrules it by sending us a size that fits the nominal
    height settings.

Jan is our hints expert.  Maybe he has an idea.

martin

Previous Next

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