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

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

bug#25330: emacs -q always produces an emacs that was partially off scre


From: martin rudalics
Subject: bug#25330: emacs -q always produces an emacs that was partially off screen.
Date: Thu, 05 Jan 2017 11:05:55 +0100

> (I had to go back and do C-u 0 C-x C-e to get rid of truncation.)

I evaluate idioms like

(insert (format "\n%s" (pp (frame-parameters))))

in *scratch* instead.

> In the bad initial off window state:
>
> icewm's size command (ALT+F8) shows
> 79x35+606+41

I don't know what the first two values stand for.  The 3rd and 4th
values are later reported by ‘frame-geometry’ as

> (frame-geometry)((outer-position 606 . 41) (outer-size 760 . 743)

so Emacs and icewm agree about this.  Now 41 + 743 give 784 which is
clearly larger than the 768 reported by

> (display-monitor-attributes-list)(((name . "LVDS-1") (geometry 0 0 1366
> 768) (workarea 0 0 1366 768) (mm-size 344 193) (frames #<frame
> address@hidden 0x12ffc30>) (source . "Gdk")))

so icewm is (IMHO) to blame for positioning the frame with a vertical
offset of 41.  In fact, 743 < 768 so the frame should fit if it were
positioned "sensibly".

I also don't like that your height of the workarea is the same as the
height of the monitor.  In your snapshot I see a taskbar - is this a
taskbar that gets hidden automatically?

> (frame-parameters)(... (top . 41) (left . 606) ...
> (width . 80) (height . 36)

Here you see the position values as before and the default width and
height values for your initial frame, 80 x 36.

> Now after I grab the window and move it to its proper place on screen:
> I get
> 79x35+606+3
>
> (display-monitor-attributes-list)(((name . "LVDS-1") (geometry 0 0 1366
> 768) (workarea 0 0 1366 768) (mm-size 344 193) (frames #<frame
> address@hidden 0x12ffc30>) (source . "Gdk")))
>
> (frame-geometry)((outer-position 606 . 3) (outer-size 760 . 743)
> (external-border-size 4 . 4) (title-bar-size 0 . 20) (menu-bar-external
> . t) (menu-bar-size 752 . 25) (tool-bar-external . t) (tool-bar-position
> . top) (tool-bar-size 752 . 42) (internal-border-width . 0))

Clearly with a vertical offset of 3 the frame fits.

> That's all. The only special thing about my icewm set up is
> $ find .icewm/ -size 0
> .icewm/menu
> .icewm/toolbar
> .icewm/keys

Do you have any other "fairly large window" say in the 750 pixels height
category that gets positioned off screen in a similar way?  Also, do you
have any Emacs related settings in some .Xresources?

> In my maximized window, there is no icewm size command available, and I get
>
> (display-monitor-attributes-list)(((name . "LVDS-1") (geometry 0 0 1366
> 768) (workarea 0 0 1366 768) (mm-size 344 193) (frames #<frame
> E06:53macs 0x12ffc30>) (source . "Gdk")))
>
> (frame-geometry)((outer-position -4 . -4) (outer-size 1368 . 748)
> (external-border-size 4 . 4) (title-bar-size 0 . 20) (menu-bar-external
> . t) (menu-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position .
> top) (tool-bar-size 0 . 0) (internal-border-width . 0))

These figures look good: The outer window is set off by -4 pixels so the
external border is not shown on either side.  Correct?  In addition it
seems to leave 768 - 748 - 8 that is 28 pixels for the taskbar (the
lower external border is drawn below the taskbar, I presume).

So there isn't much Emacs itself can do about this.  From you snapshot
it isn't clear to me whether the xterm window is fully visible - IIUC it
also gets partly hidden beneath the taskbar.  This would hint at a
problem with icewm not recognizing your taskbar.  (I don't assume that
the xterm window is maximized - this would contradict your statement
that a maximized window like the Emacs one is shown correctly.)

Obviously, you could try, in your .emacs, to either reduce the initial
or default height of your frame but this sounds ludicrous given the fact
that icewm deliberately throws away part of the available space.  Also
you could explicitly ask for an initial position which is, however,
silly because it overrides the placement strategy of the window manager.
You could explicitly specify the ‘top’ value alone like in

(setq default-frame-alist '((top . 3)))

to get rid of the manual readjustment but I have no idea whether your
window manager will like it.  Or try another window manager ...

martin






reply via email to

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