bug#3643: minibuffer beyond end of screen in emacs23

bug#3643: minibuffer beyond end of screen in emacs23

[jidanni]

Can you believe with emacs23, the first time user doing
$ emacs
will get an emacs with the minibuffer inaccessible off the user's
monitor?!

That's right, all he needs is a laptop as regular sized as the one Dr. Stallman
carries around, AND he uses X-windows.

Try this test in emacs23
$ xrdb /dev/null
$ seq 222 > /tmp/v
$ emacs -Q /tmp/v # minibuffer inaccessible off the user's monitor, same with -q
$ emacs -Q -eval '(tool-bar-mode 0)' /tmp/v # needed for emacs23

On my monitor, the file is shown with the bottom line being emacs22: 38,
emacs23: 36.

The problem is with emacs23 the minibuffer is inaccessible, beyond the
bottom.

Apparently developers never tested on anything less than long luxurious
screens or used icewm or something.

emacs-version "23.0.94.1"

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

On my 800x480 eeepc,
$ emacs -Q
ALT+F8 says the window is 21 lines high.
Since the minibuffer is below the screen, in the scratch buffer, type
(tool-bar-mode)C-x C-e
The tool bar dissapears, ALT+F8 still reports the screen is 21 lines long,
but finally all fits.
Is this an icewm bug, reporting the same size with or without toolbar?
Wait, it is counting screen lines, not pixels...
$ emacs -Q --eval '(tool-bar-mode)' #gives a window too short. ALT+F8
says it is 19 lines high.

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

jidanni@jidanni.org skrev:
> On my 800x480 eeepc,
> $ emacs -Q
> ALT+F8 says the window is 21 lines high.
> Since the minibuffer is below the screen, in the scratch buffer, type
> (tool-bar-mode)C-x C-e
> The tool bar dissapears, ALT+F8 still reports the screen is 21 lines long,
> but finally all fits.
> Is this an icewm bug, reporting the same size with or without toolbar?
> Wait, it is counting screen lines, not pixels...

Depending on which Emacs version (Gtk+, Lucid, ...) the tool bar may or may 
not be counted in the lines available for editing, that is what the window 
manager reports.

> $ emacs -Q --eval '(tool-bar-mode)' #gives a window too short. ALT+F8
> says it is 19 lines high.

Too short for what?  How tall the initial frame becomes when no height has 
been specified is undefined, i.e. it can be anything.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

I've checked in a fix.
Note that the emacs frame can still end up outside the visible area, icewm 
doesn't take care of placing Emacs at +0+0 when that is what it takes to make 
Emacs fully visible.  Moving Emacs there should make Emacs fully visible.
The adjustment of size to the desktop may not work if a bigger font is set in 
elisp.

	Jan D.


jidanni@jidanni.org skrev:
> On my 800x480 eeepc,
> $ emacs -Q
> ALT+F8 says the window is 21 lines high.
> Since the minibuffer is below the screen, in the scratch buffer, type
> (tool-bar-mode)C-x C-e
> The tool bar dissapears, ALT+F8 still reports the screen is 21 lines long,
> but finally all fits.
> Is this an icewm bug, reporting the same size with or without toolbar?
> Wait, it is counting screen lines, not pixels...
> $ emacs -Q --eval '(tool-bar-mode)' #gives a window too short. ALT+F8
> says it is 19 lines high.

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

JD> I've checked in a fix.
Thanks. I'll test it upon the next Debian emacs-snapshot.

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

Sorry, with emacs-snapshot version 1:20100118-1 there is still no
improvement.
$ emacs -Q
does not fit on the users screen under icewm.
Did you try it under icewm?

OK, today I also tried it under LXDE.
emacs -Q comes up... and the minibuffer is hidden underneath the LXDE
toolbar!

Here's what I did.
# aptitude install lxde
$ cat .xsession # http://wiki.lxde.org/en/Debian
exec startlxde
# nohup /etc/init.d/xdm restart

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

jidanni@jidanni.org skrev:
> Sorry, with emacs-snapshot version 1:20100118-1 there is still no
> improvement.
> $ emacs -Q
> does not fit on the users screen under icewm.

Please provide details and screen shots.  Like how many lines did emacs have, 
how many fits, did you start with -Q, do you change font, what is your display 
resolution.

> Did you try it under icewm?
>

Yes, with 1024x768 and 800x600 with various fonts.


> OK, today I also tried it under LXDE.
> emacs -Q comes up... and the minibuffer is hidden underneath the LXDE
> toolbar!
> 
> Here's what I did.
> # aptitude install lxde
> $ cat .xsession # http://wiki.lxde.org/en/Debian
> exec startlxde
> # nohup /etc/init.d/xdm restart

Again, details are missing.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

JD> Again, details are missing.
Can you provide me with a script that I can run that will gather the
exact information you need beyond the screenshots and details I gave
earlier in this bug. For instance, as a total font dummy that I am, I
need a script that can tell you what fonts it is using, because I don't
really know... better yet, perhaps the Debian people can enhance their
report-emacs-bug function so it will provide the missing information
beyond what it gives currently:

In GNU Emacs 23.1.91.1 (i486-pc-linux-gnu, GTK+ Version 2.18.6)
 of 2010-01-19 on elegiac, modified by Debian
 (emacs-snapshot package, version 1:20100118-1)
Windowing system distributor `The X.Org Foundation', version 11.0.10704000
configured using `configure  '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.1.91/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1.91/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: zh_TW.UTF-8
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: zh_TW.UTF-8
  value of $XMODIFIERS: @im=SCIM
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<escape> x r e p o r <tab> C-g <escape> x r e p o <tab> 
r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Making completion list...

Load-path shadows:
/usr/share/emacs/23.1.91/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/23.1.91/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/23.1.91/lisp/tempo
/usr/share/emacs/23.1.91/site-lisp/css-mode/css-mode hides /usr/share/emacs/23.1.91/lisp/textmodes/css-mode

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 hex-util hashcash mail-utils emacsbug help-mode easymenu view
china-util tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win
x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind font-render-setting gtk
x-toolkit x multi-tty emacs)

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

jidanni@jidanni.org skrev:
> JD> Again, details are missing.
> Can you provide me with a script that I can run that will gather the
> exact information you need beyond the screenshots and details I gave
> earlier in this bug. For instance, as a total font dummy that I am, I
> need a script that can tell you what fonts it is using, because I don't
> really know... better yet, perhaps the Debian people can enhance their
> report-emacs-bug function so it will provide the missing information
> beyond what it gives currently:

Just put the cursor on one character in Emacs *scratch* buffer and do
C-u C-x =

That gives you the font.

% xwininfo -all
and click in Emacs gives window sizes.

% xwininfo -frame
and click the window manager title bar for Emacs gives size of the title bar.

That last part may be it though.  As the title bar size isn't known at frame 
create time, we can't adjust for it.  I'll have to think about that.

A better strategy might be if 40 lines doesn't seem to fit, just try 20.
If that doesn't seem to fit, try 10.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

$ pstree -alA
  |-xdm
  |   |-Xorg :0 vt7 -nolisten tcp -dpi 84 -auth /var/lib/xdm/authdir/authfiles/A:0-KYG4mA
  |   `-xdm
  |       `-ck-launch-sessi /usr/bin/dbus-launch --exit-with-session sh /home/jidanni/.xsession
  |           |-sh /home/jidanni/.xsession
  |           |   |-icewm-session
  |           |   |   |-icewm
  |           |   |   |-icewmbg
  |           |   |   `-icewmtray
  |           |   `-xterm -class UXTerm -title uxterm -u8
  |           |       `-bash
  |           |           |-bash
  |           |           |   `-emacs-snapshot -Q

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

>>>>> "JD" == Jan Djärv <jan.h.d@swipnet.se> writes:
JD> Just put the cursor on one character in Emacs *scratch* buffer and do
JD> C-u C-x =
JD> That gives you the font.
        character: ; (59, #o73, #x3b)
preferred charset: ascii (ASCII (ISO646 IRV))
       code point: 0x3B
           syntax: < 	which means: comment
         category: .:Base, a:ASCII, l:Latin, r:Roman
      buffer code: #x3B
        file code: #x3B (encoded by coding system utf-8-unix)
          display: by this font (glyph code)
    xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1 (#x1E)

Character code properties: customize what to show
  name: SEMICOLON
  general-category: Po (Punctuation, Other)

There are text properties here:
  face                 font-lock-comment-delimiter-face
  fontified            t
JD> % xwininfo -all
JD> and click in Emacs gives window sizes.
xwininfo: Window id: 0x1800016 "emacs-snapshot@jidanni2.jidanni.org"

  Root window id: 0xff (the root window) (has no name)
  Parent window id: 0xc17c1b (has no name)
     2 children:
     0x1800033 (has no name): ()  672x680+0+62  +4+98
     0x1800017 (has no name): ()  1x1+-1+-1  +3+35

  Absolute upper-left X:  4
  Absolute upper-left Y:  36
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 672
  Height: 742
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +4+36  -348+36  -348--10  +4--10
  -geometry 80x40+0+12

  Bit gravity: NorthWestGravity
  Window gravity: NorthWestGravity
  Backing-store hint: NotUseful
  Backing-planes to be preserved: 0xffffffff
  Backing pixel: 0
  Save-unders: No

  Someone wants these events:
      KeyPress
      KeyRelease
      ButtonPress
      ButtonRelease
      EnterWindow
      LeaveWindow
      PointerMotion
      Exposure
      VisibilityChange
      StructureNotify
      FocusChange
      PropertyChange
      ColormapChange
  Do not propagate these events:
  Override redirection?: No

  Window manager hints:
      Client accepts input or input focus: Yes
      Initial state is Normal State

  Normal window size hints:
      Program supplied minimum size: 48 by 96
      Program supplied base size: 32 by 62
      Program supplied x resize increment: 8
      Program supplied y resize increment: 17
      Program supplied minimum size in resize increments: 6 by 5
      Program supplied base size in resize increments:  4 by 3
      Program supplied window gravity: NorthWestGravity
  No zoom window size hints defined

  No window shape defined
  No border shape defined
JD> % xwininfo -frame
JD> and click the window manager title bar for Emacs gives size of the title bar.
xwininfo: Window id: 0xc000bf (has no name)

  Absolute upper-left X:  0
  Absolute upper-left Y:  742
  Relative upper-left X:  0
  Relative upper-left Y:  742
  Width: 1024
  Height: 26
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: yes
  Corners:  +0+742  -0+742  -0-0  +0-0
  -geometry 1024x26+0-0
JD> That last part may be it though.  As the title bar size isn't known at
JD> frame create time, we can't adjust for it.  I'll have to think about
JD> that.
All I know is firefox etc. never was bigger than xwindows.
JD> A better strategy might be if 40 lines doesn't seem to fit, just try 20.
JD> If that doesn't seem to fit, try 10.
Well if it can detect that it can't fit then maybe it can detect how big
it should be.
OK, I did xwininfo -all in Firefox, just for comparison. It fits
perfectly. Of course this is not a vanilla install of firefox, all I
know is the vertical dimensions of emacs should be no bigger, as this
fits perfectly.
xwininfo: Window id: 0x1a00039 "WWWOFFLE Index - Last Time Online Pages - Iceweasel"

  Root window id: 0xff (the root window) (has no name)
  Parent window id: 0xc18ec6 (has no name)
     2 children:
     0x1a000f3 (has no name): ()  1020x719+0+0  +4+23
        1 child:
        0x1a0008f (has no name): ()  1020x719+0+0  +4+23
           1 child:
           0x1a000f2 (has no name): ()  1020x604+0+93  +4+116
              1 child:
              0x1a0019a (has no name): ()  1005x589+0+0  +4+116
     0x1a0003a (has no name): ()  1x1+-1+-1  +3+22

  Absolute upper-left X:  4
  Absolute upper-left Y:  23
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1020
  Height: 719
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +4+23  -0+23  -0-26  +4-26
  -geometry 1020x719+0+-1

  Bit gravity: NorthWestGravity
  Window gravity: NorthWestGravity
  Backing-store hint: NotUseful
  Backing-planes to be preserved: 0xffffffff
  Backing pixel: 0
  Save-unders: No

  Someone wants these events:
      KeyPress
      KeyRelease
      ButtonPress
      ButtonRelease
      EnterWindow
      LeaveWindow
      PointerMotion
      Exposure
      VisibilityChange
      StructureNotify
      FocusChange
      PropertyChange
      ColormapChange
  Do not propagate these events:
  Override redirection?: No

  Window manager hints:
      Client accepts input or input focus: Yes
      Initial state is Normal State

  Normal window size hints:
      Program supplied minimum size: 0 by 0
      Program supplied window gravity: NorthWestGravity
  No zoom window size hints defined

  No window shape defined
  No border shape defined

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

jidanni@jidanni.org skrev:
>>>>>> "JD" == Jan Djärv <jan.h.d@swipnet.se> writes:
> JD> That last part may be it though.  As the title bar size isn't known at
> JD> frame create time, we can't adjust for it.  I'll have to think about
> JD> that.
> All I know is firefox etc. never was bigger than xwindows.
> JD> A better strategy might be if 40 lines doesn't seem to fit, just try 20.
> JD> If that doesn't seem to fit, try 10.
> Well if it can detect that it can't fit then maybe it can detect how big
> it should be.

Actually, it can only detect when it is way too big.  In the case when it 
almost fits, i.e. off by one line or so, it must guess.

> OK, I did xwininfo -all in Firefox, just for comparison. It fits
> perfectly. Of course this is not a vanilla install of firefox, all I
> know is the vertical dimensions of emacs should be no bigger, as this
> fits perfectly.

The main reason is that Firefox calculates its window height before mapping 
the window.  Emacs on the other hand first maps with tool bar off and later 
adds that (in lisp) and the menu bar.  Font changes in lisp are also applied 
after the window is shown.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[martin rudalics]

 > The main reason is that Firefox calculates its window height before
 > mapping the window.  Emacs on the other hand first maps with tool bar
 > off and later adds that (in lisp) and the menu bar.  Font changes in
 > lisp are also applied after the window is shown.

The main reason is that adding/removing the toolbar or changing the font
are allowed to change the height of the Emacs frame in order to keep the
number of displayed lines constant.  This looks like an eternal pain to
me.  Can't we make this feature customizable at least?

martin

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

martin rudalics skrev:
>  > The main reason is that Firefox calculates its window height before
>  > mapping the window.  Emacs on the other hand first maps with tool bar
>  > off and later adds that (in lisp) and the menu bar.  Font changes in
>  > lisp are also applied after the window is shown.
> 
> The main reason is that adding/removing the toolbar or changing the font
> are allowed to change the height of the Emacs frame in order to keep the
> number of displayed lines constant.  This looks like an eternal pain to
> me.  Can't we make this feature customizable at least?
> 

It is not that simple, tool bar and/or menu bar may not be an integral number 
of lines.  Also, if a 10 pt font fits 20 lines perfectly on 340 pixels, an 11 
point font doesn't fit an integral number of lines in 340 pixels, it takes 342 
  or 324.
Now most applications don't care, as they aren't text editors, so they don't 
try to display an integral of text lines.  However, gnome-terminal and xterm 
do, and they resize when you change font.
What to do with the excess?  Some strip at the top that picks up the slack? 
Now it got complicated.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[martin rudalics]

 > It is not that simple, tool bar and/or menu bar may not be an integral
 > number of lines.  Also, if a 10 pt font fits 20 lines perfectly on 340
 > pixels, an 11 point font doesn't fit an integral number of lines in 340
 > pixels, it takes 342  or 324.
 > Now most applications don't care, as they aren't text editors, so they
 > don't try to display an integral of text lines.  However, gnome-terminal
 > and xterm do, and they resize when you change font.

Why do we care so much about displaying integral numbers of text lines?
With side-by-side Emacs windows displaying texts with different heights
this issue is moot anyway.

 > What to do with the excess?  Some strip at the top that picks up the
 > slack? Now it got complicated.

On Windows a maximized Emacs frame initially does not occupy the entire
screen here.  After resizing the minibuffer once it does by making the
minibuffer apprently stretch below the bottom of my screen.  So at least
for running Emacs maximized these issues have been or eventually have to
be resolved.  It should be only a small step to generalize the strategy
used for maximized frames to arbitrary frame sizes.

martin

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

martin rudalics skrev:
>  > It is not that simple, tool bar and/or menu bar may not be an integral
>  > number of lines.  Also, if a 10 pt font fits 20 lines perfectly on 340
>  > pixels, an 11 point font doesn't fit an integral number of lines in 340
>  > pixels, it takes 342  or 324.
>  > Now most applications don't care, as they aren't text editors, so they
>  > don't try to display an integral of text lines.  However, gnome-terminal
>  > and xterm do, and they resize when you change font.
> 
> Why do we care so much about displaying integral numbers of text lines?
> With side-by-side Emacs windows displaying texts with different heights
> this issue is moot anyway.

It is a user interface issue to get Emacs to try to avoid showing partial 
lines, I guess.

> 
>  > What to do with the excess?  Some strip at the top that picks up the
>  > slack? Now it got complicated.
> 
> On Windows a maximized Emacs frame initially does not occupy the entire
> screen here.  After resizing the minibuffer once it does by making the
> minibuffer apprently stretch below the bottom of my screen.  So at least
> for running Emacs maximized these issues have been or eventually have to
> be resolved.  It should be only a small step to generalize the strategy
> used for maximized frames to arbitrary frame sizes.
> 

It is true that a maximized Emacs may in fact not show an integral number of 
lines.  The slack in that case is taken up by the minibuffer or the last line 
which may show a partial line.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[Stefan Monnier]

> Why do we care so much about displaying integral numbers of text lines?

IIUC this is because the redisplay code is based around the idea of
lines of texts, still.
Last I heard, Kim Storm had started work on getting rid of those
assumptions, but since he's not very active here any more, I don't know
what came of it.  If someone else wants to pick up this work, that would
be great,


        Stefan

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

Jan Djärv skrev:
> jidanni@jidanni.org skrev:
>>>>>>> "JD" == Jan Djärv <jan.h.d@swipnet.se> writes:
>> JD> That last part may be it though.  As the title bar size isn't 
>> known at
>> JD> frame create time, we can't adjust for it.  I'll have to think about
>> JD> that.
>> All I know is firefox etc. never was bigger than xwindows.
>> JD> A better strategy might be if 40 lines doesn't seem to fit, just 
>> try 20.
>> JD> If that doesn't seem to fit, try 10.
>> Well if it can detect that it can't fit then maybe it can detect how big
>> it should be.
> 
> Actually, it can only detect when it is way too big.  In the case when 
> it almost fits, i.e. off by one line or so, it must guess.
> 

I made some changes.  If 40 doesn't fit we try 24.  If that doesn't fit we 
just use 10.  Of course, very big window manager decorations or window manager 
placement/size algorithms may still make Emacs too big.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

I still haven't heard anybody say they can reproduce this.
Anybody still use 15" monitors in 1024x768 mode?
With icewm or lxde, there comes up emacs -Q, with its modeline and
minibuffer completely underneath the toolbar.
The first time user is aghast.
I see size 14 fonts were used.

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]

JD> I made some changes.  If 40 doesn't fit we try 24.  If that doesn't
JD> fit we just use 10.
Well, you had better also glue it to the top left of the screen, or else
your latest attempt ends up like...

[-- Attachment #2: emacs -Q minibuffer hidden --]
[-- Type: image/jpeg, Size: 13053 bytes --]

[-- Attachment #3: Type: text/plain, Size: 395 bytes --]

Or maybe you should just stick emacs in the middle of the screen, as who
knows where the users toolbar are (since apparently "we can't see them
in the dark").

Please also try
$ emacs -Q& emacs -Q& emacs -Q& emacs -Q&
Notice how the first and third have the minibuffer etc. end up
underneath the toolbar at the bottom of the screen. Only the second and
fourth are correctly fully on the screen.

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

jidanni@jidanni.org skrev 2010-01-26 00.05:
> JD>  I made some changes.  If 40 doesn't fit we try 24.  If that doesn't
> JD>  fit we just use 10.
> Well, you had better also glue it to the top left of the screen, or else
> your latest attempt ends up like...
>

No, that is what I said erlier, it is up to your window manager placement 
routine to fix stuff like this.  icewm is not so good here, but trying to fix 
shortcomings of window managers in Emacs is no use.
You can file a bug to icewm about this.

Closing this.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

>>>>> "JD" == Jan Djärv <jan.h.d@swipnet.se> writes:

JD> You can file a bug to icewm about this.
OK, I filed
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=567083

Do consider reverting your changes, as I'm afraid they didn't end up
solving the bug, but instead just ended up making emacs smaller for new
users. Sorry about that.

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

jidanni@jidanni.org skrev 2010-01-27 06.17:
>>>>>> "JD" == Jan Djärv<jan.h.d@swipnet.se>  writes:
>
> JD>  You can file a bug to icewm about this.
> OK, I filed
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=567083
>
> Do consider reverting your changes, as I'm afraid they didn't end up
> solving the bug, but instead just ended up making emacs smaller for new
> users. Sorry about that.

It is almost always easier to enlarge a window than shrinking a window that is 
too big for the screen.  Experienced user can set the sizes they want.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[Chong Yidong]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

Hi Jan,

With your latest changes, `emacs -Q' creates a frame that's 22 lines
tall, taking up only about half the height of the desktop.  I think the
Emacs 23.1 behavior was better.  See attached screenshot.

It's clear that more fine-tuning is required, so I think these changes
are best done after the release.  How about reverting them for now?


[-- Attachment #2: foo.png --]
[-- Type: image/png, Size: 30063 bytes --]

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

Chong Yidong skrev:
> Hi Jan,
> 
> With your latest changes, `emacs -Q' creates a frame that's 22 lines
> tall, taking up only about half the height of the desktop.  I think the
> Emacs 23.1 behavior was better.  See attached screenshot.
> 
> It's clear that more fine-tuning is required, so I think these changes
> are best done after the release.  How about reverting them for now?
> 

Ok.  Maybe close this bug wih WONTFIX and tell people to get a better window 
manager?  Your Emacs is too big for your desktop area, but the wm fixes that.
On compiz/metacity starting Emacs with something crazy like -geometry 
80x4000+9000+9000 still produces a window that is within bounds.

	Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[Stefan Monnier]

> Ok.  Maybe close this bug wih WONTFIX and tell people to get a better window
> manager?  Your Emacs is too big for your desktop area, but the wm
> fixes that.
> On compiz/metacity starting Emacs with something crazy like -geometry
> 80x4000+9000+9000 still produces a window that is within bounds.

I don't think that's the right answer.  I consider metacity's insistence
on preventing the user from resizing the window to be larger than the
screen to be a bug (or its insistence on preventing the user from
moving a window above the screen's top, similarly).

So I think Emacs should try to do a better job choosing a default size,
based on the screen size, such that the default size (including WM
decorations) is not larger than the screen.


        Stefan

bug#3643: emacs -Q doesn't fit on the user's screen

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> So I think Emacs should try to do a better job choosing a default size,
> based on the screen size, such that the default size (including WM
> decorations) is not larger than the screen.

I think a good interim solution is to change the default font from
Monospace-12 to Monospace-10.  On most monitors, Monospace-12 is far too
large to be usable (10 is the default in Gnome installations IIUC), and
40 lines of 12-point text cause the Emacs frame to increase past the
height of most desktop areas.

WDYT?

bug#3643: emacs -Q doesn't fit on the user's screen

[Stefan Monnier]

>> So I think Emacs should try to do a better job choosing a default size,
>> based on the screen size, such that the default size (including WM
>> decorations) is not larger than the screen.

> I think a good interim solution is to change the default font from
> Monospace-12 to Monospace-10.  On most monitors, Monospace-12 is far too
> large to be usable (10 is the default in Gnome installations IIUC), and
> 40 lines of 12-point text cause the Emacs frame to increase past the
> height of most desktop areas.

I live in a world where screens never have enough lines, so I'm all for
making the default font smaller.


        Stefan

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

JD> It is almost always easier to enlarge a window than shrinking a window
JD> that is too big for the screen.  Experienced user can set the sizes
JD> they want.
Yes but the whole point of this bug report is that we want
$ emacs -Q
to look good to the first time user right out of the box.

That emacs comes up with its feet stuck underneath the toolbar, whilst
firefox or any other program the user has ever run, don't do that, tell
him something.

bug#3643: emacs -Q doesn't fit on the user's screen

[Jan Djärv]

27 jan 2010 kl. 07.52 skrev jidanni@jidanni.org:

> JD> It is almost always easier to enlarge a window than shrinking a  
> window
> JD> that is too big for the screen.  Experienced user can set the  
> sizes
> JD> they want.
> Yes but the whole point of this bug report is that we want
> $ emacs -Q
> to look good to the first time user right out of the box.
>
> That emacs comes up with its feet stuck underneath the toolbar, whilst
> firefox or any other program the user has ever run, don't do that,  
> tell
> him something.

Change windowmanager ? :-)

     Jan D.

bug#3643: emacs -Q doesn't fit on the user's screen

[jidanni]

(On the eeepc, now emacs -Q comes glued to the top 1/2 of the screen, not
obscured, but still "like nothing I've ever seen". Same for a second
emacs -Q&).

bug#3643: Bug#567083: emacs -Q doesn't fit on the user's screen

[jidanni]

>>>>> "EMZ" == Evgeny M Zubok <evgeny.zubok@tochka.ru> writes:
EMZ> What geometry your Emacs has at start? You may provide the geometry by
EMZ> emacs' option -geometry or by resource string emacs.geometry. Please,
EMZ> add Emacs.geometry: 80x35+0+0 to ~/.Xresources and don't forget to
EMZ> update resources with xrdb. Or run emacs -Q -geometry 80x35+0+0.

However my point is that I want emacs to look good for the first time
user. The first time user experience is equivalent to
$ emacs -Q
with no geometry specifications allowed.

EMZ> Note: I'm using Emacs22 based on Xaw3d toolkit and IceWM 1.3.6
EMZ> backported to Lenny. I have run Emacs on 800x600 right now, and with
EMZ> geometry options above all seems OK.

Try this experiment with icewm.
$ mv .mozilla .mozilla.old
$ firefox
Notice how it fits nicely?
Notice how
$ emacs -Q ends up with its bottom part stuck underneath the toolbar?

bug#3643: Bug#567083: emacs -Q doesn't fit on the user's screen

[jidanni]

Be sure to Cc: 3643@debbugs.gnu.org. I'm forwarding this for you.

>>>>> "EMZ" == Evgeny M Zubok <evgeny.zubok@tochka.ru> writes:
EMZ> I've just intstalled emacs23 with GTK backend from lenny-backports. Your
EMZ> problem is reproducible, but is not reproducible with emacs22 with Xaw3d
EMZ> backend. For some reason, toolbar is appeared too late, after the moment
EMZ> when emacs window has been exposed. When toolbar appears, emacs window
EMZ> is enlarged, its bottom goes beyond the screen boundaries, and IceWM

Yes, that's what I see too. (But of course it happens so fast.)

EMZ> doesn't try to change emacs geometry to fit screen area. But... is this
EMZ> IceWM problem?

I don't know, as I'm afraid to install other window manager stuff. I did
see it with LXDE+openbox too though.

EMZ> This is my explanation (just guess). It seems that at least in GTK
EMZ> version toolbar is not integral part of editor's window. When toolbar
EMZ> appears, Emacs23 tries to preserve editor area geometry (lines
EMZ> number). This leads to the changes in window size. On the contrary,
EMZ> Emacs22 with Xaw3d calculates a window size with toolbar before it will
EMZ> be exposed. I've run emacs22 -Q -geometry 90x99+0+0 with 800x600
EMZ> resolution, and the entire window fits screen height.

Thanks for your valuable input... at least it shows I'm not on drugs.

EMZ> FYI, Emacs23 also has Xaw3d backend. You can try it and verify is this
EMZ> emacs23-gtk-only problem.

All I have installed here are emacs23 and emacs-snapshot. I'm too scared
to mess things up to test anything else.

bug#3643: Bug#567083: emacs -Q doesn't fit on the user's screen

[Evgeny M. Zubok]

jidanni@jidanni.org writes:

> EMZ> doesn't try to change emacs geometry to fit screen area. But... is this
> EMZ> IceWM problem?
>
> I don't know, as I'm afraid to install other window manager stuff. I did
> see it with LXDE+openbox too though.

I think this is right behaviour of WM: when an application changes its
size, the WM shouldn't (but may) prevent this action. As I understand
from #36430 log, Metacity (sorry, I don't use it) prevents window from
growing.

> EMZ> FYI, Emacs23 also has Xaw3d backend. You can try it and verify is this
> EMZ> emacs23-gtk-only problem.
>
> All I have installed here are emacs23 and emacs-snapshot. I'm too scared
> to mess things up to test anything else.

I've just installed emacs23-lucid (GNU Emacs 23.1.1 (i486-pc-linux-gnu,
X toolkit, Xaw3d scroll bars) of 2009-10-19 on
debian-build.int-office-er.priv, modified by Debian) from
lenny-backports, and... I havn't noticed the problem with IceWM. Emacs
window fits screen height nicely. It seems this is emacs23-gtk
feature. I don't think that this is IceWM bug.

bug#3643: Bug#567083: emacs -Q doesn't fit on the user's screen

[jidanni]

>>>>> "EMZ" == Evgeny M Zubok <evgeny.zubok@tochka.ru> writes:
EMZ> I've just installed emacs23-lucid (GNU Emacs 23.1.1 (i486-pc-linux-gnu,
EMZ> X toolkit, Xaw3d scroll bars) of 2009-10-19 on
EMZ> debian-build.int-office-er.priv, modified by Debian) from
EMZ> lenny-backports, and... I havn't noticed the problem with IceWM. Emacs
EMZ> window fits screen height nicely. It seems this is emacs23-gtk
EMZ> feature. I don't think that this is IceWM bug.

I see the bug with
$  apt-cache policy emacs23
emacs23:
  Installed: 23.1+1-6
In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.18.2)
 of 2010-01-27 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10704000
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

I haven't installed these
$ aptitude search ~nemacs.*gtk
p   emacs-snapshot-gtk
p   emacs22-gtk
v   emacs23-gtk
And I note
$ aptitude -v show emacs-snapshot-gtk
Package: emacs-snapshot-gtk
New: yes
State: not installed
Version: 1:20100125-1
Priority: optional
Section: main
Maintainer: Romain Francoise <rfrancoise@debian.org>
Uncompressed Size: 53.2k
Architecture: all
Compressed Size: 20.5k
Filename: pool/main/e/emacs-snapshot/emacs-snapshot-gtk_20100125-1_all.deb
MD5sum: 6a09b2cb079bdeb40d180ff5e7a0bb5e
Archive: unstable
Depends: emacs-snapshot <-------
PreDepends: dpkg (>= 1.14.21)
Description: The GNU Emacs editor (transitional package)
 Empty package to facilitate upgrades, can be safely removed. <-------
Homepage: http://www.gnu.org/software/emacs/

bug#3643: Bug#567083: emacs -Q doesn't fit on the user's screen

[jidanni]

>>>>> "EMZ" == Evgeny M Zubok <evgeny.zubok@tochka.ru> writes:

EMZ> As I understand from the following discussion in the upstream, IceWM
EMZ> not to blame for described emacs behaviour. I think the bug should be
EMZ> reassigned to wishlist items of emacs23 package. Am I right? Upstream
EMZ> considers an interim solution to use smaller default font, but it has
EMZ> not announced what will be a final solution.

See also
  *  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3643
  *  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4995
I give up.

bug#3643: minibuffer beyond end of screen in emacs23

[Chong Yidong]

> Can you believe with emacs23, the first time user doing
> $ emacs
> will get an emacs with the minibuffer inaccessible off the user's
> monitor?!

Nowhere in your bug report do you mention the screen resolution you're
using, nor any other details that will help diagnose the problem.

bug#3643: minibuffer beyond end of screen in emacs23

[jidanni]

>> Can you believe with emacs23, the first time user doing
>> $ emacs
>> will get an emacs with the minibuffer inaccessible off the user's
>> monitor?!

CY> Nowhere in your bug report do you mention the screen resolution you're
CY> using, nor any other details that will help diagnose the problem.

Sorry. I thought checking at common resolutions like 1024x768 would
reproduce the problem.

bug#3643: minibuffer beyond end of screen in emacs23

[Stefan Monnier]

>> Can you believe with emacs23, the first time user doing
>> $ emacs
>> will get an emacs with the minibuffer inaccessible off the user's
>> monitor?!

> Nowhere in your bug report do you mention the screen resolution you're
> using, nor any other details that will help diagnose the problem.

Actually he did say it, in a Jidanni-way:

   ...a laptop as regular sized as the one Dr. Stallman carries around...

IIUC Richard's Lemote Yeeloong's netbook uses a standard 1024x600
display (same as the one I have on the MSI Wind on which I'm typing
this).


        Stefan

bug#3643: minibuffer beyond end of screen in emacs23

[jidanni]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

> Can you believe with emacs23, the first time user doing
> $ emacs
> will get an emacs with the minibuffer inaccessible off the user's
> monitor?!

Proof at 1024x768:

[-- Attachment #2: off of screen --]
[-- Type: image/png, Size: 68148 bytes --]

[-- Attachment #3: Type: text/plain, Size: 26 bytes --]

emacs-version "23.0.95.1"

bug#3643: minibuffer beyond end of screen in emacs23

[jidanni]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Say did
>> $ emacs
>> extend beyond the screen for you too?
SM> I think so, yes, tho with my window manager (ctwm) I get to resize at
SM> the same time as the frame is created (actually, placed), and with my
SM> default config (small fonts, no menubar, no toolbar) the problem
SM> doesn't appear.
I used xdm->icewm for a user with no dotfiles on 1024x768 to reproduce
the bug, which is surely "the size of the bed emacs ordered for himself
did not include his hat (toolbar), that he likes to wear. That is why
his feet busted through the end boards (and went off the screen)".

bug#3643: minibuffer beyond end of screen in emacs23

[Chong Yidong]

Do you still see this problem with latest Emacs from CVS trunk?

bug#3643: minibuffer beyond end of screen in emacs23

[jidanni]

>>>>> "CY" == Chong Yidong <cyd@stupidchicken.com> writes:
CY> Do you still see this problem with latest Emacs from CVS trunk?
Yes, happens still in this version:
--- Changes for emacs-snapshot (emacs-snapshot-common emacs-snapshot-el emacs-snapshot-bin-common emacs-snapshot) ---
emacs-snapshot (1:20091023-1) unstable; urgency=low

  * New snapshot.

 -- Romain Francoise <rfrancoise@debian.org>  Fri, 23 Oct 2009 18:52:51 +0200