GNU bug report logs - #58
Shrinking frames as of past month

Previous Next

Package: emacs;

Reported by: Michael Olson <mwolson <at> gnu.org>

Date: Mon, 17 Mar 2008 13:40:05 UTC

Severity: normal

Tags: wontfix

Merged with 44

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

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58 in the body.
You can then email your comments to 58 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#58; Package emacs. Full text and rfc822 format available.

Acknowledgement sent to Michael Olson <mwolson <at> gnu.org>:
New bug report received and forwarded. Copy sent to Emacs Bugs <bug-gnu-emacs <at> gnu.org>. Full text and rfc822 format available.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Michael Olson <mwolson <at> gnu.org>
To: emacs-devel <at> gnu.org
Subject: Shrinking frames as of past month
Date: Sun, 16 Mar 2008 21:20:35 -0700
<#part sign=pgpmime>
When I replaced my Emacs binary that was compiled in February with one
compiled from today's CVS HEAD, I noticed some very aberrant behavior
WRT frames.  I haven't updated the rest of my system in that time, such
as libraries, so it must be due to a change in Emacs.  It happens with
"emacs -Q" as well, so it's not caused to my init file.

Basically, GTK frames seem to shrink by about one character length every
time I do certain things such hitting viewing mail on Gnus, hitting the
key combination "M-x", or displaying an image by hitting RET on it in
dired.

The easiest way to replicate this is to view a directory which contains
image files in dired, and hit RET on one of them.  The frame will
shrink.  Hit C-x b to switch back and forth between the image and the
directory, and the frame will shrink further.  It might be necessary to
initially have the frame small enough that a line-wrap indicator shows
up in the fringe.

I also notice then when I resize the frames back to take up the original
amount of pixels in width, that the window manager thinks the dimensions
of the window are different than they are.  In two frames with the same
number of pixels long, and with Emacs displaying the same number of
characters, one is thought to be 80x35 by the window manager and the
other one (the one that shrank earlier) is thought to be 70x35.

Here are my compilation options:

Configured for `i686-pc-linux-gnu'.

  Where should the build process find the source code?    /stuff/proj/emacs/emacs/git-emacs
  What operating system and machine description files should Emacs use?
        `s/gnu-linux.h' and `m/intel386.h'
  What compiler should emacs be built with?               gcc -g -O2 -Wno-pointer-sign 
  Should Emacs use the GNU version of malloc?             yes
      (Using Doug Lea's new malloc from the GNU C Library.)
  Should Emacs use a relocating allocator for buffers?    yes
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          GTK
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use -lpng?                                   yes
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  yes
  Does Emacs use a font backend?                          yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   yes
  Does Emacs use X toolkit scroll bars?                   yes

  Compiling with sync input.

Using --disable-sync-input did not make any difference.

-- 
|       Michael Olson  |  FSF Associate Member #652     |
| http://mwolson.org/  |  Hobbies: Lisp, HCoop          |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'






Information forwarded to bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#58; Package emacs. Full text and rfc822 format available.

Acknowledgement sent to Michael Olson <mwolson <at> gnu.org>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs <at> gnu.org>. Full text and rfc822 format available.

Message #10 received at 58 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Michael Olson <mwolson <at> gnu.org>
To: Jan Djarv <jan.h.d <at> swipnet.se>
Cc: emacs-devel <at> gnu.org, 58 <at> debbugs.gnu.org
Subject: Re: Shrinking frames as of past month
Date: Tue, 18 Mar 2008 18:11:06 -0700
[Message part 1 (text/plain, inline)]
Jan Djärv <jan.h.d <at> swipnet.se> writes:

> Michael Olson skrev:
>> When I replaced my Emacs binary that was compiled in February with
>> one compiled from today's CVS HEAD, I noticed some very aberrant
>> behavior WRT frames.  I haven't updated the rest of my system in that
>> time, such as libraries, so it must be due to a change in Emacs.  It
>> happens with "emacs -Q" as well, so it's not caused to my init file.
>>
>> Basically, GTK frames seem to shrink by about one character length
>> every time I do certain things such hitting viewing mail on Gnus,
>> hitting the key combination "M-x", or displaying an image by hitting
>> RET on it in dired.
>
> Does this always involves an image, or does it happen when you view
> ordinary text mail in Gnus also?

It happens when viewing ordinary text as well, particularly if there are
2 windows on the frame.

-- 
|       Michael Olson  |  FSF Associate Member #652     |
| http://mwolson.org/  |  Hobbies: Lisp, HCoop          |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#58; Package emacs. Full text and rfc822 format available.

Message #13 received at 58 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Francesc Rocher <francesc.rocher <at> gmail.com>
Cc: sds <at> gnu.org, emacs-devel <at> gnu.org
Subject: Re: Shrinking frames as of past month
Date: Sat, 22 Mar 2008 12:55:19 +0100
Francesc Rocher skrev:
> Sam Steingold wrote:
> 
>> |> Basically, GTK frames seem to shrink by about one character length every
>> |> time I do certain things such hitting viewing mail on Gnus, hitting the
>> |> key combination "M-x", or displaying an image by hitting RET on it in
>> |> dired.
>> |
>> | Does this always involves an image, or does it happen when you view
>> | ordinary text mail in Gnus also?
>>
>>
>> I get it on entering dired (no images involved)
> 
> Yes, me too, but only on the initial frame. This effect disapears on
> subsequent frames.
> 

It seems it is a bug in Gtk+, http://bugzilla.gnome.org/show_bug.cgi?id=68668
(http://bugzilla.gnome.org/show_bug.cgi?id=137822 explains it a bit better).

Basically because the menu bar is too large for the frame, Gtk+ sets a base
width that isn't a multiple of the width increment.  This makes the window
manager shrink the text area (by 2 pixels in my case) so that framw width -
base width is a multiple of the width increment.  Then when leaving dired, we
get a correct base width again.  But the 2 pixels aren't put back, rather the
window manager shrinks even more to get the frame to be a multiple of the
width increment.

So for me I get (my width inc is 6 pixels)

enter dired => shrink 2 pixels,
leave dired => shrink 4 pixels,
enter dired => shrink 2 pixels,
...
and so on.

There is talk about a workaround in the gnome-terminal sources, I'll check it out.

If the menu bar is disabled, or the size of the frame is large enough to show
the whole dired menubar, shrinking does not occur.

	Jan D.





Merged 44 58. Request was from Stefan Monnier <monnier <at> iro.umontreal.ca> to control <at> emacsbugs.donarmstrong.com. (Sat, 22 Mar 2008 17:25:06 GMT) Full text and rfc822 format available.

Tags added: wontfix Request was from Stefan Monnier <monnier <at> iro.umontreal.ca> to control <at> emacsbugs.donarmstrong.com. (Sat, 22 Mar 2008 17:25:06 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 44 <at> debbugs.gnu.org and Sebastian Luque <spluque <at> gmail.com> Request was from Lars Magne Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 02 Jul 2011 22:14:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 31 Jul 2011 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 14 years and 20 days ago.

Previous Next


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