GNU bug report logs -
#3643
minibuffer beyond end of screen in emacs23
Previous Next
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 #129 received at 3643 <at> debbugs.gnu.org (full text, mbox):
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.
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.