* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
@ 2010-01-15 12:14 ` jidanni
2010-01-15 15:31 ` Jan Djärv
2010-01-15 17:08 ` Jan Djärv
2010-01-16 1:10 ` jidanni
` (9 subsequent siblings)
10 siblings, 2 replies; 37+ messages in thread
From: jidanni @ 2010-01-15 12:14 UTC (permalink / raw)
To: jan.h.d; +Cc: rfrancoise, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-15 12:14 ` bug#3643: emacs -Q doesn't fit on the user's screen jidanni
@ 2010-01-15 15:31 ` Jan Djärv
2010-01-15 17:08 ` Jan Djärv
1 sibling, 0 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-15 15:31 UTC (permalink / raw)
To: jidanni; +Cc: rfrancoise, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-15 12:14 ` bug#3643: emacs -Q doesn't fit on the user's screen jidanni
2010-01-15 15:31 ` Jan Djärv
@ 2010-01-15 17:08 ` Jan Djärv
1 sibling, 0 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-15 17:08 UTC (permalink / raw)
To: jidanni; +Cc: rfrancoise, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
2010-01-15 12:14 ` bug#3643: emacs -Q doesn't fit on the user's screen jidanni
@ 2010-01-16 1:10 ` jidanni
2010-01-20 3:57 ` jidanni
` (8 subsequent siblings)
10 siblings, 0 replies; 37+ messages in thread
From: jidanni @ 2010-01-16 1:10 UTC (permalink / raw)
To: jan.h.d; +Cc: rfrancoise, 3643
JD> I've checked in a fix.
Thanks. I'll test it upon the next Debian emacs-snapshot.
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
2010-01-15 12:14 ` bug#3643: emacs -Q doesn't fit on the user's screen jidanni
2010-01-16 1:10 ` jidanni
@ 2010-01-20 3:57 ` jidanni
2010-01-20 6:26 ` Jan Djärv
2010-01-20 6:49 ` jidanni
` (7 subsequent siblings)
10 siblings, 1 reply; 37+ messages in thread
From: jidanni @ 2010-01-20 3:57 UTC (permalink / raw)
To: jan.h.d; +Cc: rfrancoise, 3643
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
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 3:57 ` jidanni
@ 2010-01-20 6:26 ` Jan Djärv
0 siblings, 0 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-20 6:26 UTC (permalink / raw)
To: jidanni; +Cc: rfrancoise, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
` (2 preceding siblings ...)
2010-01-20 3:57 ` jidanni
@ 2010-01-20 6:49 ` jidanni
2010-01-20 7:18 ` Jan Djärv
2010-01-20 6:53 ` jidanni
` (6 subsequent siblings)
10 siblings, 1 reply; 37+ messages in thread
From: jidanni @ 2010-01-20 6:49 UTC (permalink / raw)
To: jan.h.d; +Cc: rfrancoise, 3643
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)
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 6:49 ` jidanni
@ 2010-01-20 7:18 ` Jan Djärv
0 siblings, 0 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-20 7:18 UTC (permalink / raw)
To: jidanni; +Cc: rfrancoise, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
` (3 preceding siblings ...)
2010-01-20 6:49 ` jidanni
@ 2010-01-20 6:53 ` jidanni
2010-01-20 7:31 ` jidanni
` (5 subsequent siblings)
10 siblings, 0 replies; 37+ messages in thread
From: jidanni @ 2010-01-20 6:53 UTC (permalink / raw)
To: jan.h.d; +Cc: rfrancoise, 3643
$ 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
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
` (4 preceding siblings ...)
2010-01-20 6:53 ` jidanni
@ 2010-01-20 7:31 ` jidanni
2010-01-20 8:27 ` Jan Djärv
2010-01-21 23:53 ` jidanni
` (4 subsequent siblings)
10 siblings, 1 reply; 37+ messages in thread
From: jidanni @ 2010-01-20 7:31 UTC (permalink / raw)
To: jan.h.d; +Cc: rfrancoise, 3643
>>>>> "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
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 7:31 ` jidanni
@ 2010-01-20 8:27 ` Jan Djärv
2010-01-20 9:27 ` martin rudalics
2010-01-25 7:52 ` Jan Djärv
0 siblings, 2 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-20 8:27 UTC (permalink / raw)
To: jidanni; +Cc: rfrancoise, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 8:27 ` Jan Djärv
@ 2010-01-20 9:27 ` martin rudalics
2010-01-20 9:58 ` Jan Djärv
2010-01-25 7:52 ` Jan Djärv
1 sibling, 1 reply; 37+ messages in thread
From: martin rudalics @ 2010-01-20 9:27 UTC (permalink / raw)
To: Jan Djärv; +Cc: rfrancoise, 3643, jidanni
> 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 9:27 ` martin rudalics
@ 2010-01-20 9:58 ` Jan Djärv
2010-01-20 10:59 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Jan Djärv @ 2010-01-20 9:58 UTC (permalink / raw)
To: martin rudalics; +Cc: rfrancoise, 3643, jidanni
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 9:58 ` Jan Djärv
@ 2010-01-20 10:59 ` martin rudalics
2010-01-20 11:14 ` Jan Djärv
2010-01-21 14:12 ` Stefan Monnier
0 siblings, 2 replies; 37+ messages in thread
From: martin rudalics @ 2010-01-20 10:59 UTC (permalink / raw)
To: Jan Djärv; +Cc: rfrancoise, 3643, jidanni
> 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 10:59 ` martin rudalics
@ 2010-01-20 11:14 ` Jan Djärv
2010-01-21 14:12 ` Stefan Monnier
1 sibling, 0 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-20 11:14 UTC (permalink / raw)
To: martin rudalics; +Cc: rfrancoise, 3643, jidanni
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 10:59 ` martin rudalics
2010-01-20 11:14 ` Jan Djärv
@ 2010-01-21 14:12 ` Stefan Monnier
1 sibling, 0 replies; 37+ messages in thread
From: Stefan Monnier @ 2010-01-21 14:12 UTC (permalink / raw)
To: martin rudalics; +Cc: rfrancoise, 3643, jidanni
> 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-20 8:27 ` Jan Djärv
2010-01-20 9:27 ` martin rudalics
@ 2010-01-25 7:52 ` Jan Djärv
1 sibling, 0 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-25 7:52 UTC (permalink / raw)
To: jidanni; +Cc: rfrancoise, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
` (5 preceding siblings ...)
2010-01-20 7:31 ` jidanni
@ 2010-01-21 23:53 ` jidanni
2010-01-25 23:05 ` jidanni
` (3 subsequent siblings)
10 siblings, 0 replies; 37+ messages in thread
From: jidanni @ 2010-01-21 23:53 UTC (permalink / raw)
To: 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
` (6 preceding siblings ...)
2010-01-21 23:53 ` jidanni
@ 2010-01-25 23:05 ` jidanni
2010-01-26 6:56 ` Jan Djärv
2010-01-27 5:17 ` jidanni
` (2 subsequent siblings)
10 siblings, 1 reply; 37+ messages in thread
From: jidanni @ 2010-01-25 23:05 UTC (permalink / raw)
To: jan.h.d; +Cc: 3643
[-- 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.
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-25 23:05 ` jidanni
@ 2010-01-26 6:56 ` Jan Djärv
0 siblings, 0 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-26 6:56 UTC (permalink / raw)
To: jidanni; +Cc: 3643-done, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
` (7 preceding siblings ...)
2010-01-25 23:05 ` jidanni
@ 2010-01-27 5:17 ` jidanni
2010-01-27 6:21 ` Jan Djärv
2010-01-27 6:52 ` jidanni
2010-01-27 10:15 ` jidanni
10 siblings, 1 reply; 37+ messages in thread
From: jidanni @ 2010-01-27 5:17 UTC (permalink / raw)
To: jan.h.d; +Cc: 3643
>>>>> "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.
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-27 5:17 ` jidanni
@ 2010-01-27 6:21 ` Jan Djärv
2010-01-28 2:23 ` Chong Yidong
0 siblings, 1 reply; 37+ messages in thread
From: Jan Djärv @ 2010-01-27 6:21 UTC (permalink / raw)
To: jidanni; +Cc: 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-27 6:21 ` Jan Djärv
@ 2010-01-28 2:23 ` Chong Yidong
2010-01-28 7:18 ` Jan Djärv
0 siblings, 1 reply; 37+ messages in thread
From: Chong Yidong @ 2010-01-28 2:23 UTC (permalink / raw)
To: Jan Djärv; +Cc: 3643, jidanni
[-- 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 --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-28 2:23 ` Chong Yidong
@ 2010-01-28 7:18 ` Jan Djärv
2010-01-28 19:06 ` Stefan Monnier
0 siblings, 1 reply; 37+ messages in thread
From: Jan Djärv @ 2010-01-28 7:18 UTC (permalink / raw)
To: Chong Yidong; +Cc: 3643, jidanni
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-28 7:18 ` Jan Djärv
@ 2010-01-28 19:06 ` Stefan Monnier
2010-01-29 16:36 ` Chong Yidong
0 siblings, 1 reply; 37+ messages in thread
From: Stefan Monnier @ 2010-01-28 19:06 UTC (permalink / raw)
To: Jan Djärv; +Cc: Chong Yidong, 3643, jidanni
> 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
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-28 19:06 ` Stefan Monnier
@ 2010-01-29 16:36 ` Chong Yidong
2010-01-29 18:52 ` Stefan Monnier
0 siblings, 1 reply; 37+ messages in thread
From: Chong Yidong @ 2010-01-29 16:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 3643, jidanni
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?
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-29 16:36 ` Chong Yidong
@ 2010-01-29 18:52 ` Stefan Monnier
0 siblings, 0 replies; 37+ messages in thread
From: Stefan Monnier @ 2010-01-29 18:52 UTC (permalink / raw)
To: Chong Yidong; +Cc: 3643, jidanni
>> 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
` (8 preceding siblings ...)
2010-01-27 5:17 ` jidanni
@ 2010-01-27 6:52 ` jidanni
2010-01-27 9:00 ` Jan Djärv
2010-01-27 10:15 ` jidanni
10 siblings, 1 reply; 37+ messages in thread
From: jidanni @ 2010-01-27 6:52 UTC (permalink / raw)
To: jan.h.d; +Cc: rms, 3643
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.
^ permalink raw reply [flat|nested] 37+ messages in thread* bug#3643: emacs -Q doesn't fit on the user's screen
2010-01-27 6:52 ` jidanni
@ 2010-01-27 9:00 ` Jan Djärv
0 siblings, 0 replies; 37+ messages in thread
From: Jan Djärv @ 2010-01-27 9:00 UTC (permalink / raw)
To: jidanni@jidanni.org; +Cc: rms@gnu.org, 3643@debbugs.gnu.org
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#3643: emacs -Q doesn't fit on the user's screen
2009-06-21 20:50 bug#3643: minibuffer beyond end of screen in emacs23 jidanni
` (9 preceding siblings ...)
2010-01-27 6:52 ` jidanni
@ 2010-01-27 10:15 ` jidanni
10 siblings, 0 replies; 37+ messages in thread
From: jidanni @ 2010-01-27 10:15 UTC (permalink / raw)
To: 3643
(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&).
^ permalink raw reply [flat|nested] 37+ messages in thread
![[-- Attachment #2: emacs -Q minibuffer hidden --] [-- Type: image/jpeg, Size: 13053 bytes --]](../../87hbq9aipo.fsf@jidanni.org/2-emacs-snapshot20100125.jpg){kind=link}
![[-- Attachment #2: foo.png --] [-- Type: image/png, Size: 30063 bytes --]](../../878wbj6k77.fsf@stupidchicken.com/2-foo.png){kind=link}