* Shrinking frames as of past month
@ 2008-03-17 4:20 Michael Olson
2008-03-18 7:56 ` Jan Djärv
0 siblings, 1 reply; 12+ messages in thread
From: Michael Olson @ 2008-03-17 4:20 UTC (permalink / raw)
To: emacs-devel
<#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 |
`-------------------------------------------------------'
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
2008-03-17 4:20 Shrinking frames as of past month Michael Olson
@ 2008-03-18 7:56 ` Jan Djärv
2008-03-19 1:11 ` Michael Olson
2008-03-19 16:06 ` Sam Steingold
0 siblings, 2 replies; 12+ messages in thread
From: Jan Djärv @ 2008-03-18 7:56 UTC (permalink / raw)
To: Michael Olson; +Cc: emacs-devel
Michael Olson skrev:
> <#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.
Does this always involves an image, or does it happen when you view ordinary
text mail in Gnus also?
>
> 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.
Cool, we have shrinkage in both dimensions now :-).
>
> 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.
>
That is wm size hints that aren't updated properly. The bug is why the frame
shrinks when viewing an image. I can reproduce it, so a fix should be done
within a couple of days or so.
Jan D.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
2008-03-18 7:56 ` Jan Djärv
@ 2008-03-19 1:11 ` Michael Olson
2008-03-19 16:06 ` Sam Steingold
1 sibling, 0 replies; 12+ messages in thread
From: Michael Olson @ 2008-03-19 1:11 UTC (permalink / raw)
To: Jan Djarv; +Cc: 58, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
Jan Djärv <jan.h.d@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 |
`-------------------------------------------------------'
[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
2008-03-18 7:56 ` Jan Djärv
2008-03-19 1:11 ` Michael Olson
@ 2008-03-19 16:06 ` Sam Steingold
1 sibling, 0 replies; 12+ messages in thread
From: Sam Steingold @ 2008-03-19 16:06 UTC (permalink / raw)
To: emacs-devel; +Cc: Michael Olson, emacs-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Djärv wrote:
|
|
| Michael Olson skrev:
|> <#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.
|
| 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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH4Tn4Pp1Qsf2qnMcRAmdgAKCXobXbjP6pdGxDqkkjAhzzMNSDtACaAvFI
qRQt8rGi6wpQ+jwYvjeVhW0=
=RAnF
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
@ 2008-03-19 20:16 Francesc Rocher
2008-03-22 11:55 ` Jan Djärv
2008-03-30 17:39 ` Jan Djärv
0 siblings, 2 replies; 12+ messages in thread
From: Francesc Rocher @ 2008-03-19 20:16 UTC (permalink / raw)
To: sds, emacs-devel
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.
--
Francesc Rocher
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
2008-03-19 20:16 Francesc Rocher
@ 2008-03-22 11:55 ` Jan Djärv
2008-03-23 21:38 ` Michael Olson
2008-03-30 17:39 ` Jan Djärv
1 sibling, 1 reply; 12+ messages in thread
From: Jan Djärv @ 2008-03-22 11:55 UTC (permalink / raw)
To: Francesc Rocher; +Cc: sds, emacs-devel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
2008-03-22 11:55 ` Jan Djärv
@ 2008-03-23 21:38 ` Michael Olson
2008-03-28 9:33 ` Andrew W. Nosenko
0 siblings, 1 reply; 12+ messages in thread
From: Michael Olson @ 2008-03-23 21:38 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]
Jan Djärv <jan.h.d@swipnet.se> writes:
> 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.
That sounds plausible. I updated the rest of my system today, and the
problem went away, so it seems to have been the fault of GTK.
--
| Michael Olson | FSF Associate Member #652 |
| http://mwolson.org/ | Hobbies: Lisp, HCoop |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'
[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
2008-03-23 21:38 ` Michael Olson
@ 2008-03-28 9:33 ` Andrew W. Nosenko
2008-03-28 10:35 ` Jan Djärv
0 siblings, 1 reply; 12+ messages in thread
From: Andrew W. Nosenko @ 2008-03-28 9:33 UTC (permalink / raw)
To: Michael Olson; +Cc: emacs-devel
On Sun, Mar 23, 2008 at 11:38 PM, Michael Olson <mwolson@gnu.org> wrote:
> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>
> > 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.
>
> That sounds plausible. I updated the rest of my system today, and the
> problem went away, so it seems to have been the fault of GTK.
>
Could you say, which version of GTK you updated to?
Reason: I have lates stable (gtk-2.12.9) but problem didn't gone.
--
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
2008-03-28 9:33 ` Andrew W. Nosenko
@ 2008-03-28 10:35 ` Jan Djärv
0 siblings, 0 replies; 12+ messages in thread
From: Jan Djärv @ 2008-03-28 10:35 UTC (permalink / raw)
To: Andrew W. Nosenko; +Cc: Michael Olson, emacs-devel
Andrew W. Nosenko skrev:
> On Sun, Mar 23, 2008 at 11:38 PM, Michael Olson <mwolson@gnu.org> wrote:
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>
>>
>>> 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.
>>
>> That sounds plausible. I updated the rest of my system today, and the
>> problem went away, so it seems to have been the fault of GTK.
>>
>
> Could you say, which version of GTK you updated to?
> Reason: I have lates stable (gtk-2.12.9) but problem didn't gone.
>
I don't think the problem is fixed, the bugzilla entry is still open.
You don't see the problem if your frame is wide enough to make room for direds
menu bar, or if you don't have the menu bar visible. I suspect that is what
happens.
It might also be pure luck. I.e. the font used by the menu bar is such that
the base width happens to be a multiple of the width increment. Or perhaps a
newer Gtk+ calculates the base width slightly differently.
Jan D.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Shrinking frames as of past month
2008-03-19 20:16 Francesc Rocher
2008-03-22 11:55 ` Jan Djärv
@ 2008-03-30 17:39 ` Jan Djärv
2008-03-30 19:03 ` Francesc Rocher
1 sibling, 1 reply; 12+ messages in thread
From: Jan Djärv @ 2008-03-30 17:39 UTC (permalink / raw)
To: Francesc Rocher; +Cc: sds, emacs-devel
This should be fixed now. Please test.
Jan D.
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.
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-03-31 6:21 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-17 4:20 Shrinking frames as of past month Michael Olson
2008-03-18 7:56 ` Jan Djärv
2008-03-19 1:11 ` Michael Olson
2008-03-19 16:06 ` Sam Steingold
-- strict thread matches above, loose matches on Subject: below --
2008-03-19 20:16 Francesc Rocher
2008-03-22 11:55 ` Jan Djärv
2008-03-23 21:38 ` Michael Olson
2008-03-28 9:33 ` Andrew W. Nosenko
2008-03-28 10:35 ` Jan Djärv
2008-03-30 17:39 ` Jan Djärv
2008-03-30 19:03 ` Francesc Rocher
2008-03-31 6:21 ` Jan Djärv
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.