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

Previous Next

Package: emacs;

Reported by: jidanni <at> jidanni.org

Date: Sun, 21 Jun 2009 21:40:12 UTC

Severity: normal

Merged with 4995

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


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.




This bug report was last modified 15 years and 95 days ago.

Previous Next


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