bug#7004: 23.2; In fullscreen mode, the echo area takes too much vertical space

[Jan Djärv]

Eli Zaretskii skrev 2010-09-13 21.18:
> > Date: Mon, 13 Sep 2010 20:59:27 +0200
> > From: Jan Djärv<jan.h.d@swipnet.se>
> > CC: david@harpegolden.net, 7004@debbugs.gnu.org
> >
> > The resizing is constrained to increments of the font size, so it is not
> > possible to resize it manually to a fraction of the font size.
> > If we remove that constraint by editing the source it will show the same
> > behavour, extra pixels are unused at the bottom of the frame.
>
> So it's probably some detail of how the windows are redisplayed that
> leaves the mini-window with the extra space, instead of giving it to
> the previous window.
>
> > But I don't know of any function that sizes a window by pixels.  All the
> > resizing code does is to calculate rows and columns from the pixel sizes and
> > the call change_frame_size.  That in turn resizes windows, but just based on
> > lines and columns, not pixels AFAIK.
>
> Doesn't the fullscreen option on X resize _the_frame_ instead of
> windows?

Yes, but when the new size is communicated Emacs reacts to the new frame size 
with change_frame_size, and then windows are also resized.

> > I see that W32 does that also, so how can it be different?
>
> On Windows, the fullscreen I tried was by sending a special command to
> the window manager.  I'm guessing that this resizes the frame, and
> then Emacs's redisplay simply uses what it's got.  I will have to look
> at the sources to see if my guess is correct.

On X Emacs also just uses what its got.  But I don't understand how a window 
can be made not an integral if the font size.  The only thing that is 
externally resized is the frame.  Windows, mode lines and minibuffer are 
handeled, resized and positioned by Emacs. I just can't find any way to 
resize/position those based on anything except increments of the font size.

        Jan D.