bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Tue, 12 Jan 2010 14:22:01 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Steve Revilak skrev:
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

                                * * *

I've been trying Emacs 23.1.91 on an OpenSUSE 11.2 system.

Linux srevilak 2.6.31.5-0.1-desktop #1 SMP PREEMPT 2009-10-26 15:49:03 +0100 i686 i686 i386 GNU/Linux

In general, this prerelease seems to work very well.  However, I have
had difficulty getting Emacs 23.1.91 to respect geometry settings.  I
will frame this bug report as a series of (expected, observed) pairs.
In this context, "expected" refers to the the behavior of

 # this is the emacs that comes with OpenSUSE 11.2
GNU Emacs 23.1.1 (i586-suse-linux-gnu, GTK+ Version 2.18.1) of 2009-12-02 on build15

and "observed" refers to the behavior of Emacs 23.1.91.

I will also try to be mindful of the recent change in -Q's behavior.

All cases lack data. Do you have a font set in X resources? What window manager are you using? Do you set a font in .emacs? Do your desktop contain panels or fixed menu bars?

Geometry tests for emacs are only reliable if the font and size is known at startup and doesn't change in elisp (.emacs or site-wide .el-file).
I.e. in X resources or from the command line.

Also note that a window manager is totally free to ignore and override any or all parts of a geometry specification.



CASE 1: Geometry from ~/.Xresources
-----------------------------------

I have the (only) following line in ~/.Xresources

  emacs.geometry: 86x46-2+0

Expected: emacs starts with dimensions 86x46, two pixels from the
right edge of the screen, and zero pixels from the top edge of the
screen.

Observed: Emacs starts with dimensions 86x25 (not 86x46).  The initial
frame is two pixels from the right edge of the screen, but 225 pixels
from the top edge of the screen (not 0 pixels from the top edge of the
screen).

So you probably have a font change done in .emacs. This is to be expected, the font change is done after the first frame is shown, so the frame shrinks.


CASE 2: Geometry from Command Line
----------------------------------

I've started emacs as
  emacs --no-init-file --no-site-file --geometry 86x46+0+0

Expected: Emacs starts with an 86x46 frame, with the upper left corner
of the frame in the upper left corner of the screen.

Observed: Emacs starts with an 86x28 frame.  The frame is positioned
against the right edge of the screen, but 225 pixels from the top of
the screen.


CASE 3: Geometry from Command Line (only width and height specified)
--------------------------------------------------------------------

Start emacs as

  emacs --no-init-file --no-site-file --geometry 86x46

Expected: Emacs starts with an 86x46 frame, with the frame positioned
at coordinates -2+0.  (Here the -2+0 was inherited from .Xresources).

Whst do you have in Xresources? X does not inherit part of geometry from one place and another part from another place. You can not expect it to pop up at -2+0 if you don't say so, and you didn't. You said: "size 86x46, position undefined".


Actual: Emacs starts with an 86x28 frame, with the frame positioned at
-2+225 (225 pixels from the top of the screen)


More likely your window manager remembered where the frame popped up last and since Emacs didn't specify a position, the window manager used the remembered position (some do that).


CASE 4: Geometry from the Command Line (but smaller frame size)
--------------------------------------------------------------

Start emacs as

  emacs --no-init-file --no-site-file --geometry 60x30+0+0

Expected: Emacs starts with a 60x30 frame, positioned in the upper
left corner of the screen.

Actual: Same as expected. This is interesting. Given a smaller frame size, emacs 23.1.91
exhibited the same behavior as emacs 23.1.1.


So your window manager isn't interfering here. The initial font fits so no shrinkage is done.


Further pursuit of CASE 4:
-------------------------

I continued to experiment with different geometry sizes.  At a height
of 44, emacs with the default font fills the vertical space of the
screen.  At height > 44, emacs _appears_ to say "this frame is too
tall for the screen, so I'm going to use a different height".

That is your window managers doing.


If height 44 fills the vertical space of the screen, then why do I have
86x46 in ~/.Xresources?  My .emacs uses (set-frame-font) to change
fonts.  The font I'm using is a little smaller than the default font,
whereby height 46 fits nicely on the screen, with a little room to
spare at the bottom.

If it matters, here is my (set-frame-font) call

(set-frame-font "-efont-fixed-medium-r-normal--16-160-75-75-c-80-iso10646-1")


The set-frame-font is done after all the geometry has been parsed and acted upon, and possibly modified by your window manager. So you try 46 with the original font, your window manager descides that is too big and shrinks the frame. The font then changes and the frame shrinks again.

Other observations:
------------------

Moving the font setting from ~/.emacs to ~/.Xresources did not work.


In what sense? The font wasn't used, emacs crashed, the computer burned up, the frame is too big/small?

        Jan D.






reply via email to

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