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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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