GNU bug report logs - #3643
minibuffer beyond end of screen in emacs23

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3643 in the body.
You can then email your comments to 3643 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jidanni <at> jidanni.org
To: bug-gnu-emacs <at> gnu.org
Subject: minibuffer beyond end of screen in emacs23
Date: Mon, 22 Jun 2009 04:50:41 +0800

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"

Message #10 received at 3643 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: jidanni <at> jidanni.org
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: minibuffer beyond end of screen in emacs23
Date: Mon, 22 Jun 2009 16:02:15 -0400

> 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.

Message #15 received at 3643 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jidanni <at> jidanni.org
To: cyd <at> stupidchicken.com
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: minibuffer beyond end of screen in emacs23
Date: Tue, 23 Jun 2009 05:39:27 +0800

>> 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.

Message #20 received at 3643 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#3643: minibuffer beyond end of screen in emacs23
Date: Sat, 27 Jun 2009 03:31:04 +0200

>> 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

Message #25 received at 3643 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jidanni <at> jidanni.org
To: monnier <at> iro.umontreal.ca
Cc: cyd <at> stupidchicken.com, 3643 <at> debbugs.gnu.org
Subject: Re: bug#3643: minibuffer beyond end of screen in emacs23
Date: Sun, 28 Jun 2009 07:58:00 +0800

[Message part 1 (text/plain, inline)]

> 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:

[emacs.png (image/png, attachment)]

[Message part 3 (text/plain, inline)]

emacs-version "23.0.95.1"

Message #30 received at 3643 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jidanni <at> jidanni.org
To: monnier <at> iro.umontreal.ca
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: minibuffer beyond end of screen in emacs23
Date: Wed, 01 Jul 2009 05:23:37 +0800

>>>>> "SM" == Stefan Monnier <monnier <at> 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)".

Message #35 received at 3643 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jidanni <at> jidanni.org
To: 3643 <at> debbugs.gnu.org
Date: Thu, 20 Aug 2009 04:46:59 +0800

Even more snapshots in bug#4087.

Message #40 received at 3643 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: jidanni <at> jidanni.org
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: minibuffer beyond end of screen in emacs23
Date: Fri, 23 Oct 2009 12:06:47 -0400

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

Message #45 received at 3643 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jidanni <at> jidanni.org
To: cyd <at> stupidchicken.com
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: minibuffer beyond end of screen in emacs23
Date: Sat, 24 Oct 2009 03:31:45 +0800

>>>>> "CY" == Chong Yidong <cyd <at> 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 <at> debian.org>  Fri, 23 Oct 2009 18:52:51 +0200

Message #48 received at submit <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#3643 23.1.90.1; menu, toolbars vs. constant size
Date: Tue, 05 Jan 2010 05:41:07 +0800

In emacs -Q fiddle in the menus, clicking
<menu-bar> <options> <showhide> <showhide-tool-bar> etc.

Notice how emacs cannot keep itself constant size, but the whole of
emacs grows and shrinks along with its tool and menu bars.

Now contrast this with firefox, View-> [check/uncheck some tool etc.
bars]

Notice how the whole of firefox stays the same size.

In emacs one must first click the "maximize" button in the upper right
corner for things to work out well, and such changes not to change
emacs's total size.

For firefox, that one clicked "maximize" is remembered between sessions.

For emacs I have to use the complicated
http://jidanni.org/comp/configuration/ just to get a full size window
without the bars at startup.

Message #51 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org, 3643 <at> debbugs.gnu.org
Subject: Re: bug#3643: 23.1.90.1; menu, toolbars vs. constant size
Date: Wed, 06 Jan 2010 12:14:19 +0100

jidanni <at> jidanni.org skrev 2010-01-04 22.41:
> In emacs -Q fiddle in the menus, clicking
> <menu-bar>  <options>  <showhide>  <showhide-tool-bar>  etc.
>
> Notice how emacs cannot keep itself constant size, but the whole of
> emacs grows and shrinks along with its tool and menu bars.
>
> Now contrast this with firefox, View->  [check/uncheck some tool etc.
> bars]
>
> Notice how the whole of firefox stays the same size.

Emacs is not firefox.  Emacs tries to keep editable lines so of course size 
changes.  Apparently Firefox does not, but that has no bearing on Emacs.
The size of the toolbar/menubar may not be an integral number of text lines. 
Emacs tries to always show whole lines, Firefox does not.

You may put wish list as severity on this bug, but please describe every 
possible combination Emacs can hav in this respect and how it should behave. 
This includes tiling window managers like XMonad, and running with no window 
manager at all.  And how Emacs should behave w.r.t. resize in all scenarios.

>
> In emacs one must first click the "maximize" button in the upper right
> corner for things to work out well, and such changes not to change
> emacs's total size.
>
> For firefox, that one clicked "maximize" is remembered between sessions.
>
> For emacs I have to use the complicated
> http://jidanni.org/comp/configuration/ just to get a full size window
> without the bars at startup.
>

emacs.toolBar: 0
emacs.menuBar: 0

and start emacs with -fs is all it takes.  Not very complicated.

In the future, please use M-x report-emacs-bug.  As different ports have 
different behaviour, we would like to know what you are running.

	Jan D.

Message #54 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: bug#3643: 23.1.90.1; menu, toolbars vs. constant size
Date: Thu, 07 Jan 2010 18:21:52 +0800

>> http://jidanni.org/comp/configuration/ just to get a full size window
>> without the bars at startup.
JD> emacs.toolBar: 0
JD> emacs.menuBar: 0
$ xrdb -q
emacs.ToolBar:	0
emacs.toolBar:	0
emacs.menuBar:	0
emacs.MenuBar:	0
Emacs.ToolBar:	0
Emacs.toolBar:	0
Emacs.menuBar:	0
Emacs.MenuBar:	0
$ emacs -Q #still has the tool and menu bars there as plain as day.
And the minibuffer is still way below the bottom of the screen.
JD> and start emacs with -fs is all it takes.
That covers over my icewm toolbar which is not what I want.
Is there any solution that would fit completely into ~/.emacs?
JD> we would like to know what you are running.
emacs-snapshot:
  Version table:
 *** 1:20100106-1 0
        500 http://emacs.orebokech.com sid/main Packages
and http://jidanni.org/comp/configuration/
Anyway, today I'm running emacs on an eeepc,
25 lines tall + 1 for mode line + 1 for minibuffer.
Then below that is an about two lines tall icewm toolbar, up at top is a
one line tall icewm window title bar. Bet you guys never tested on such
small windows. emacs -Q just doesn't fit.

Message #57 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: bug#3643: 23.1.90.1; menu, toolbars vs. constant size
Date: Thu, 07 Jan 2010 12:19:18 +0100

jidanni <at> jidanni.org skrev:
>>> http://jidanni.org/comp/configuration/ just to get a full size window
>>> without the bars at startup.
> JD> emacs.toolBar: 0
> JD> emacs.menuBar: 0
> $ xrdb -q
> emacs.ToolBar:	0
> emacs.toolBar:	0
> emacs.menuBar:	0
> emacs.MenuBar:	0
> Emacs.ToolBar:	0
> Emacs.toolBar:	0
> Emacs.menuBar:	0
> Emacs.MenuBar:	0
> $ emacs -Q #still has the tool and menu bars there as plain as day.

Well, -Q ignores X resources, try -q instead.

> And the minibuffer is still way below the bottom of the screen.
> JD> and start emacs with -fs is all it takes.
> That covers over my icewm toolbar which is not what I want.

That is a descision made by icewm, Emacs has nothing to do with it.  You could 
try -mm also.

> Is there any solution that would fit completely into ~/.emacs?

No, as the size of the first frame is calculated before your settings in 
.emacs takes effect.

> JD> we would like to know what you are running.
> emacs-snapshot:
>   Version table:
>  *** 1:20100106-1 0
>         500 http://emacs.orebokech.com sid/main Packages
> and http://jidanni.org/comp/configuration/

This doesn't say anything, use M-x report-emacs-bug.

> Anyway, today I'm running emacs on an eeepc,
> 25 lines tall + 1 for mode line + 1 for minibuffer.
> Then below that is an about two lines tall icewm toolbar, up at top is a
> one line tall icewm window title bar. Bet you guys never tested on such
> small windows. emacs -Q just doesn't fit.

Emacs windows can be as small as 3 lines.  It may not fit by default, but it 
sure can be made to fit.

	Jan D.

Message #60 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: bug#3643: 23.1.90.1; menu, toolbars vs. constant size
Date: Sat, 09 Jan 2010 12:18:28 +0800

!.Xresources
Emacs.toolBar: 0
Emacs.menuBar: 0
and emacs -q it turns out work... unless one wants to use a different
font! Then one needs -mm.
Is there any way to put the -mm into .emacs? or does one need a shell wrapper?
emacs-version "23.1.91.1"
Anyway, my point still remains, the user's first encounter with
$ emacs # just won't fit on many people's screens.
At least under icewm. I don't know any other program that acts like that
right out of the box.

Message #63 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: bug#3643: 23.1.90.1; menu, toolbars vs. constant size
Date: Sat, 09 Jan 2010 14:30:41 +0100

jidanni <at> jidanni.org skrev:
> !.Xresources
> Emacs.toolBar: 0
> Emacs.menuBar: 0
> and emacs -q it turns out work... unless one wants to use a different
> font! Then one needs -mm.
> Is there any way to put the -mm into .emacs? or does one need a shell wrapper?

The documentation for emacs and elisp is in info.  It can be confusing that 
some parts are in the Emacs node and some in the Elisp node.  This particular 
documentation is in the Elisp node: In Emacs:
C-h i m elisp<return> s maximized <return>

I.e. the frame parameter fullscreen can have the value maximized.

> emacs-version "23.1.91.1"
> Anyway, my point still remains, the user's first encounter with
> $ emacs # just won't fit on many people's screens.
> At least under icewm. I don't know any other program that acts like that
> right out of the box.

That is indeed a bad thing to do.  I added some code to address that.  Note 
that any tool bars put there by the window manager must be handeled by the 
window manager.  For example, compiz will never let me create a window so high 
it covers the menu/toolbars added by Gnome-panel.

	Jan D.

Message #66 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: 3643 <at> debbugs.gnu.org
Cc: jan.h.d <at> swipnet.se, rfrancoise <at> debian.org
Subject: emacs -Q doesn't fit on the user's screen
Date: Wed, 13 Jan 2010 07:07:30 +0800

On 09 Jan 2010
JD> That is indeed a bad thing to do.  I added some code to address that.

OK, but
$ emacs -Q
still won't fit on many screens, at least under icewm. Compare firefox.

I thought

  GNU Emacs 23.1.91.1 (i486-pc-linux-gnu, GTK+ Version 2.18.5)
  of 2010-01-12 on elegiac, modified by Debian
  (emacs-snapshot package, version 1:20100111-1)

However
$ zcat /usr/share/doc/emacs-snapshot-common/changelog.gz|head -n 1
2010-01-02  Eli Zaretskii  <eliz <at> gnu.org>

So that date is misleading...

Message #69 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 13 Jan 2010 08:42:18 +0100

On 2010-01-13 00:07, jidanni <at> jidanni.org wrote:
> On 09 Jan 2010
> JD>  That is indeed a bad thing to do.  I added some code to address that.
>
> OK, but
> $ emacs -Q
> still won't fit on many screens, at least under icewm. Compare firefox.
>
> I thought
>
>    GNU Emacs 23.1.91.1 (i486-pc-linux-gnu, GTK+ Version 2.18.5)
>    of 2010-01-12 on elegiac, modified by Debian
>    (emacs-snapshot package, version 1:20100111-1)

I don't know how often Debian takes its snapshot or how it relates to 
bzr trunk.  To really test it, get Emacs from the bzr repository on 
savannah.

>
> However
> $ zcat /usr/share/doc/emacs-snapshot-common/changelog.gz|head -n 1
> 2010-01-02  Eli Zaretskii<eliz <at> gnu.org>
>
> So that date is misleading...

The date is from when Emacs was built.

	Jan D.

Message #72 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: jidanni <at> jidanni.org, 3643 <at> debbugs.gnu.org
Cc: rfrancoise <at> debian.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Wed, 13 Jan 2010 09:37:52 +0200

jidanni <at> jidanni.org wrote:
>   (emacs-snapshot package, version 1:20100111-1)
> 
> However
> $ zcat /usr/share/doc/emacs-snapshot-common/changelog.gz|head -n 1
> 2010-01-02  Eli Zaretskii  <eliz <at> gnu.org>
> 
> So that date is misleading...

Not misleading at all.  That file is the toplevel ChangeLog; the
others are at /usr/share/doc/emacs-snapshot-common/changelogs.

Message #75 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Romain Francoise <romain <at> orebokech.com>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 13 Jan 2010 09:49:46 +0100

"Jan D." <jan.h.d <at> swipnet.se> writes:

>>    GNU Emacs 23.1.91.1 (i486-pc-linux-gnu, GTK+ Version 2.18.5)
>>    of 2010-01-12 on elegiac, modified by Debian
>>    (emacs-snapshot package, version 1:20100111-1)

> I don't know how often Debian takes its snapshot or how it relates
> to bzr trunk. To really test it, get Emacs from the bzr repository
> on savannah.

The snapshots are taken from the bzr trunk; this particular version
was built at the date shown in the version (2010-01-12). If it
helps, the corresponding bzr revision was 99300.

Message #78 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 13 Jan 2010 12:24:44 +0100

On 2010-01-13 00:07, jidanni <at> jidanni.org wrote:
> On 09 Jan 2010
> JD> That is indeed a bad thing to do. I added some code to address that.
>
> OK, but
> $ emacs -Q
> still won't fit on many screens, at least under icewm. Compare firefox.

This is very uninformative.  Screen esolution? Font used? Size that 
fits? Size that Emacs uses? Screen shots?

	Jan D.

Message #81 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: romain <at> orebokech.com
Cc: jan.h.d <at> swipnet.se, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Thu, 14 Jan 2010 05:14:08 +0800

RF> The snapshots are taken from the bzr trunk; this particular version
RF> was built at the date shown in the version (2010-01-12). If it
RF> helps, the corresponding bzr revision was 99300.

OK, then the following should in the future please mention more of those
facts.

>>> GNU Emacs 23.1.91.1 (i486-pc-linux-gnu, GTK+ Version 2.18.5)
>>> of 2010-01-12 on elegiac, modified by Debian
>>> (emacs-snapshot package, version 1:20100111-1)

Or at least mention the 99300. Thanks.

Message #84 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Thu, 14 Jan 2010 11:48:18 +0800

JD> Screen esolution? Font used? Size that fits? Size that Emacs uses?
JD> Screen shots?

I enclosed a screen shot earlier in this bug.
$ xdpyinfo|grep dimensions
  dimensions:    1024x768 pixels (302x232 millimeters)
As far as what fonts emacs -Q uses, I did C-u C-x = on the first word in
the *scratch* buffer and found:
    xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1 (#x37)

It starts up 80+40, says ALT+F8 here in icewm.
But only 80+38 will fit.

Message #87 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Fri, 15 Jan 2010 20:14:26 +0800

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.

Message #90 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Fri, 15 Jan 2010 16:31:42 +0100

jidanni <at> 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.

Message #93 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Fri, 15 Jan 2010 18:08:57 +0100

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 <at> 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.

Message #96 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Sat, 16 Jan 2010 09:10:50 +0800

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

Message #99 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 11:57:58 +0800

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

Message #102 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 07:26:12 +0100

jidanni <at> 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.

Message #105 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 14:49:04 +0800

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)

Message #108 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 14:53:20 +0800

$ 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

Message #111 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 08:18:08 +0100

jidanni <at> 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.

Message #114 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 15:31:48 +0800

>>>>> "JD" == Jan Djärv <jan.h.d <at> 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 <at> 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

Message #117 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 09:27:44 +0100

jidanni <at> jidanni.org skrev:
>>>>>> "JD" == Jan Djärv <jan.h.d <at> 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.

Message #120 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 10:27:24 +0100

> 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

Message #123 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 10:58:19 +0100

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.

Message #126 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 11:59:31 +0100

> 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

Message #129 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Wed, 20 Jan 2010 12:14:02 +0100

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.

Message #132 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, rfrancoise <at> debian.org,
	3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Thu, 21 Jan 2010 09:12:44 -0500

> 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

Message #135 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Fri, 22 Jan 2010 07:53:43 +0800

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.

Message #140 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: rfrancoise <at> debian.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Mon, 25 Jan 2010 08:52:15 +0100

Jan Djärv skrev:
> jidanni <at> jidanni.org skrev:
>>>>>>> "JD" == Jan Djärv <jan.h.d <at> 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.

Message #143 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Tue, 26 Jan 2010 07:05:39 +0800

[Message part 1 (text/plain, inline)]

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...

[emacs-snapshot20100125.jpg (image/jpeg, attachment)]

[Message part 3 (text/plain, inline)]

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.

Message #146 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: 3643-done <at> debbugs.gnu.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Tue, 26 Jan 2010 07:56:09 +0100

jidanni <at> 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.

Message #159 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 27 Jan 2010 13:17:54 +0800

>>>>> "JD" == Jan Djärv <jan.h.d <at> 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.

Message #162 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: jidanni <at> jidanni.org
Cc: 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 27 Jan 2010 07:21:06 +0100

jidanni <at> jidanni.org skrev 2010-01-27 06.17:
>>>>>> "JD" == Jan Djärv<jan.h.d <at> 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.

Message #165 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jan.h.d <at> swipnet.se
Cc: rms <at> gnu.org, 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 27 Jan 2010 14:52:47 +0800

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.

Message #168 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: "jidanni <at> jidanni.org" <jidanni <at> jidanni.org>
Cc: "rms <at> gnu.org" <rms <at> gnu.org>, "3643 <at> debbugs.gnu.org" <3643 <at> debbugs.gnu.org>
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 27 Jan 2010 10:00:13 +0100

27 jan 2010 kl. 07.52 skrev jidanni <at> 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.

Message #171 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: 3643 <at> debbugs.gnu.org
Subject: Re: emacs -Q doesn't fit on the user's screen
Date: Wed, 27 Jan 2010 18:15:36 +0800

(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&).

Message #174 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Wed, 27 Jan 2010 21:23:56 -0500

[Message part 1 (text/plain, inline)]

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?

[foo.png (image/png, attachment)]

Message #177 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 3643 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Thu, 28 Jan 2010 08:18:23 +0100

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.

Message #180 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 3643 <at> debbugs.gnu.org,
	jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Thu, 28 Jan 2010 14:06:59 -0500

> 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

Message #183 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 3643 <at> debbugs.gnu.org,
	567083 <at> bugs.debian.org
Subject: Re: Bug#567083: emacs -Q doesn't fit on the user's screen
Date: Fri, 29 Jan 2010 18:50:05 +0800

>>>>> "EMZ" == Evgeny M Zubok <evgeny.zubok <at> 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?

Message #186 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: evgeny.zubok <at> tochka.ru
Cc: jan.h.d <at> swipnet.se, monnier <at> iro.umontreal.ca, 3643 <at> debbugs.gnu.org
Subject: Re: Bug#567083: emacs -Q doesn't fit on the user's screen
Date: Fri, 29 Jan 2010 19:23:16 +0800

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

>>>>> "EMZ" == Evgeny M Zubok <evgeny.zubok <at> 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.

Message #189 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: "Evgeny M. Zubok" <evgeny.zubok <at> tochka.ru>
To: jidanni <at> jidanni.org
Cc: jan.h.d <at> swipnet.se, monnier <at> iro.umontreal.ca, 3643 <at> debbugs.gnu.org
Subject: Re: Bug#567083: emacs -Q doesn't fit on the user's screen
Date: Fri, 29 Jan 2010 15:14:38 +0300

jidanni <at> 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.

Message #192 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: evgeny.zubok <at> tochka.ru
Cc: jan.h.d <at> swipnet.se, monnier <at> iro.umontreal.ca, 3643 <at> debbugs.gnu.org
Subject: Re: Bug#567083: emacs -Q doesn't fit on the user's screen
Date: Fri, 29 Jan 2010 20:33:04 +0800

>>>>> "EMZ" == Evgeny M Zubok <evgeny.zubok <at> 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 <at> 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/

Message #195 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 3643 <at> debbugs.gnu.org,
	jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Fri, 29 Jan 2010 11:36:20 -0500

Stefan Monnier <monnier <at> 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?

Message #198 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 3643 <at> debbugs.gnu.org,
	jidanni <at> jidanni.org
Subject: Re: bug#3643: emacs -Q doesn't fit on the user's screen
Date: Fri, 29 Jan 2010 13:52:01 -0500

>> 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

Message #201 received at 3643 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: evgeny.zubok <at> tochka.ru
Cc: 3643 <at> debbugs.gnu.org, 567083 <at> bugs.debian.org
Subject: Re: Bug#567083: emacs -Q doesn't fit on the user's screen
Date: Sun, 21 Feb 2010 17:45:15 +0800

>>>>> "EMZ" == Evgeny M Zubok <evgeny.zubok <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.