GNU bug report logs - #28605
26.0.60; Part of leftmost character hidden

Previous Next

Package: emacs;

Reported by: Ola Nilsson <ola.nilsson <at> gmail.com>

Date: Tue, 26 Sep 2017 09:54:02 UTC

Severity: normal

Found in version 26.0.60

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Ola Nilsson <ola.nilsson <at> gmail.com>,
 28605 <at> debbugs.gnu.org, Kaushal <kaushal.modi <at> gmail.com>
Subject: Re: bug#28605: 26.0.60; Part of leftmost character hidden
Date: Tue, 10 Oct 2017 11:15:59 +0200
> Having just reproduced it here, it's the switch from python to html
> that does it. If you do 'emacs -Q second.html' the SGML menu is
> created correctly. I get lots of
>
> (emacs:12642): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>
> as well, which may be related.

Damn.  That's the usual menu bar bug from etc/PROBLEMS.


*** Emacs built with GTK+ toolkit can unexpectedly widen frames

This resizing takes place when a frame is not wide enough to accommodate
its entire menu bar.  Typically, it occurs when switching buffers or
changing a buffer's major mode and the new mode adds entries to the menu
bar.  The frame is then widened by the window manager so that the menu
bar is fully shown.  Subsequently switching to another buffer or
changing the buffer's mode will not shrink the frame back to its
previous width.  The height of the frame remains unaltered.  Apparently,
the failure is also dependent on the chosen font.

The resizing is usually accompanied by console output like

Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

It's not clear whether the GTK version used has any impact on the
occurrence of the failure.  So far, the failure has been observed with
GTK+ versions 3.4.2, 3.14.5 and 3.18.7.  However, another 3.4.2 build
does not exhibit the bug.

Some window managers (Xfce) apparently work around this failure by
cropping the menu bar.  With other windows managers, it's possible to
shrink the frame manually after the problem occurs, e.g. by dragging the
frame's border with the mouse.  However, some window managers have been
reported to refuse such attempts and snap back to the width needed to
show the full menu bar (wmii) or at least cause the screen to flicker
during such resizing attempts (i3, IceWM).

See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15700,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22000,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22898 and
https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00154.html.


Maybe it now no more auto-widens the frame?

martin




This bug report was last modified 4 years and 319 days ago.

Previous Next


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