[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5308: 23.1.91; Geometry quirk on OpenSuSE 11.2

From: Jan Djärv
Subject: bug#5308: 23.1.91; Geometry quirk on OpenSuSE 11.2
Date: Thu, 11 Feb 2010 21:35:55 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv: Gecko/20100111 Thunderbird/3.0.1


I think there might be a bug in the window manager lurking in the background.
It resizes Emacs a lot if Emacs is too big for the display.
But if we set size hints at startup, this problem goes away.

We used to do that, but the discussion starting at
introduced a patch to not set wm hints at startup.

So it is basiacally the old startup problem again, but in a different form.
I don't know if there is much we can do about this. I'll keep looking, but as this isn't something that makes Emacs unusable, it is a low priority.

        Jan D.

Steve Revilak skrev 2010-01-14 01.33:
Date: Wed, 13 Jan 2010 08:52:00 +0100
From: "Jan D." <address@hidden>
Subject: Re: bug#5308: 23.1.91; Geometry quirk on OpenSuSE 11.2

I think your figure 2 is a proper bug. The rest is probably
interactions with the window manager. I'll have to install your
versions and check. It may take a while.

Thanks, Jan. If there's anything I can do to assist, please let me


On 2010-01-13 02:44, Steve Revilak wrote:

Thanks for responding. I'm sorry that you didn't get much useful
information from my initial report. Please let me try again, and I
will make an effort to be clearer this time.

First, I'd like to provide you with some system information.

Operating System:

(1:0)srevilak:~$ cat /etc/SuSE-release openSUSE 11.2 (i586)
VERSION = 11.2
(0:0)srevilak:~$ uname -a
Linux srevilak #1 SMP PREEMPT 2009-10-26 15:49:03
+0100 i686 i686 i386 GNU/Linux

Window Manager:

(0:0)srevilak:~$ kde4-config --version
Qt: 4.5.3
KDE: 4.3.1 (KDE 4.3.1) "release 6"
kde4-config: 1.0

Contents of .Xresources (a single line, containing a comment):

(0:0)srevilak:~$ cat .Xresources
! .Xresources

Contents of .emacs (a single line, containing a comment):

(0:0)srevilak:~$ cat .emacs
; .emacs

Finally, to be sure that ~/.Xresources agrees with our current

(0:0)srevilak:~$ xrdb .Xresources

First, I will start emacs with the command line

/usr/local/emacs-23.1.91/bin/emacs --no-init-file --no-site-file
-geometry 86x44-0+0
figure-1.png shows a snapshot of my screen after starting emacs. As
you can see, emacs occupies most of the vertical space on the screen.

Next, I will quit emacs, then run the following command line

/usr/local/emacs-23.1.91/bin/emacs --no-init-file --no-site-file
-geometry 86x45-0+0

Notice that I have increased the height from 44 to 45, which is just a
little too large to fit on the screen; the rest of the command line is
unchanged. The result of this appears in figure-2.png.

Observe that figure-1.png and figure-2.png are quite different.

As you noted before, this could be the Window Manager's doing. For my
third (and final) snapshot, I would like to provide evidence which
suggests that it is not the window manager.

/usr/bin/emacs --no-init-file --no-site-file -geometry 86x45-0+0

Above, /usr/bin/emacs is emacs 23.1.1, as packaged with OpenSUSE 11.2
(you'll see this from emacs' splash screen). The result of running
this command appears in figure-3.png. As you can see, figure-3.png
resembles figure-1.png much more than figure-2.png.

The difference between figure-2.png and figure-3.png is the core of my
issue. Specifically,

* When Emacs-23.1.1 is confronted with a geometry that is too large
for the height of the screen, then emacs-23.1.1 respects the
geometry as best as it can. In figure-3.png, we see that
Emacs-23.1.1 took up as much of the vertical screen space as was

* When Emacs-23.1.91 is confronted with a geometry that is too large
for the height of the screen, then emacs-23.1.91 does not try to
respect the geometry as best as it can. As you can see from
figure-2.png, emacs-23.1.91 opted for a much smaller height. (In
figure-2.png, you can also see a very different appearance in the
splash screen itself.)

In summary, I believe that the behavior shown in figure-3.png
(produced by
emacs-23.1.1) is more correct than the behavior shown in figure-2.png
(produced by emacs-23.1.91).

Please let me know if you'd like me to provide any additional details.

Steve Revilak

reply via email to

[Prev in Thread] Current Thread [Next in Thread]