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

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

[Dani Moncayo]

[-- Attachment #1.1: Type: text/plain, Size: 1150 bytes --]

When I put Emacs in fullscreen mode, it seems to me that the last line (echo
area/minibuffer) takes too much, unnecessary vertical space.

Test conditions:
 - emacs-version => "GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version
2.20.1) of 2010-07-31 on jesus-desktop".
 - OS: Ubuntu 10.04 (32 bits CPU).

To reproduce the bug:
 1.- Start Emacs in fullscreen: "emacs -Q -fs" (see "fullscreen.png"). Here
you will see the echo area too high.
 2.- Now, to compare, start Emacs in normal window: "emacs -Q" (see
"normal-window.png"). Here you will see the echo area properly dimensioned.


Another (i think easier) way to reproduce the bug: switch from normal window
to fullscreen mode, by using the following Elisp function:

> (defun toggle-fullscreen ()
>  (interactive)
>  (let ((current-value (frame-parameter nil 'fullscreen)))
>     (set-frame-parameter nil 'fullscreen
>             (if (equal current-value 'fullboth)
>                 (if (boundp 'old-fullscreen) old-fullscreen nil)
>               (progn (setq old-fullscreen current-value)
>                  'fullboth)))))
>
; optional shortcut
> (global-set-key [f11] 'toggle-fullscreen)
>

[-- Attachment #1.2: Type: text/html, Size: 2744 bytes --]

[-- Attachment #2: fullscreen.png --]
[-- Type: image/png, Size: 40379 bytes --]

[-- Attachment #3: normal-window.png --]
[-- Type: image/png, Size: 35764 bytes --]

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

[Jan Djärv]

Please do not post in html.

 From your picture:
The height of tool bar + menu bar is 73 pixels.
Your font height is 17 pixels.

(1024 - 73)/17 = 55.94117

The remnant (0.94117) is just wasted space, no whole line can be made to fit 
in to it so it shows up at the botton as unused space.  Any window height that 
isn't an integral of the font height will show like this.

There is no bug here,

	Jan D.

2010-09-09 17:14, Dani Moncayo skrev:
>
> When I put Emacs in fullscreen mode, it seems to me that the last line
> (echo area/minibuffer) takes too much, unnecessary vertical space.
>
> Test conditions:
>   - emacs-version => "GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version
> 2.20.1) of 2010-07-31 on jesus-desktop".
>   - OS: Ubuntu 10.04 (32 bits CPU).
>
> To reproduce the bug:
>   1.- Start Emacs in fullscreen: "emacs -Q -fs" (see "fullscreen.png").
> Here you will see the echo area too high.
>   2.- Now, to compare, start Emacs in normal window: "emacs -Q" (see
> "normal-window.png"). Here you will see the echo area properly dimensioned.
>
>
> Another (i think easier) way to reproduce the bug: switch from normal
> window to fullscreen mode, by using the following Elisp function:
>
>     (defun toggle-fullscreen ()
>       (interactive)
>       (let ((current-value (frame-parameter nil 'fullscreen)))
>          (set-frame-parameter nil 'fullscreen
>                  (if (equal current-value 'fullboth)
>                      (if (boundp 'old-fullscreen) old-fullscreen nil)
>                    (progn (setq old-fullscreen current-value)
>     'fullboth)))))
>
>     ; optional shortcut
>     (global-set-key [f11] 'toggle-fullscreen)
>
>
>
>
>
>
>
>

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

[Stefan Monnier]

> in to it so it shows up at the botton as unused space.  Any window height
> that isn't an integral of the font height will show like this.
> There is no bug here,

It's clearly not a feature, so I'd qualify it as a bug.
The bug being that Emacs's display code insists on using "character
cells" as measuring unit.  Kim had started working on lifting this
restriction, but I don't know if anything came out of it,


        Stefan

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

[Jan Djärv]

2010-09-10 14:39, Stefan Monnier skrev:
>> in to it so it shows up at the botton as unused space.  Any window height
>> that isn't an integral of the font height will show like this.
>> There is no bug here,
>
> It's clearly not a feature, so I'd qualify it as a bug.
> The bug being that Emacs's display code insists on using "character
> cells" as measuring unit.  Kim had started working on lifting this
> restriction, but I don't know if anything came out of it,
>

That doesn't matter.  When you say to the window manager to put Eamcs in 
fullscreen, the height will be 1024 pixels (if that is what you have).  And 
there will be a remainder that is not zero.  What do you purpose Emacs does 
with this extra space?  Even if we don't have any restrictions, we can't 
display a line in this leftover space.

AFAIK, the restriction to be removed is more about scroll bar width, tool bar 
and menu bar heights and so on has to be a multiple of the character width/height.

	Jan D.

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

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> That doesn't matter.  When you say to the window manager to put Eamcs in
> fullscreen, the height will be 1024 pixels (if that is what you have).
> And there will be a remainder that is not zero.  What do you purpose Emacs
> does with this extra space?  Even if we don't have any restrictions, we
> can't display a line in this leftover space.

It only requires pixel granularity for the window heights to be able to
distribute the leftover space to the windows.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Jan Djärv]

10 sep 2010 kl. 18:59 skrev Andreas Schwab <schwab@linux-m68k.org>:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> That doesn't matter.  When you say to the window manager to put Eamcs in
>> fullscreen, the height will be 1024 pixels (if that is what you have).
>> And there will be a remainder that is not zero.  What do you purpose Emacs
>> does with this extra space?  Even if we don't have any restrictions, we
>> can't display a line in this leftover space.
> 
> It only requires pixel granularity for the window heights to be able to
> distribute the leftover space to the windows.

That doesn't make sense. Distribute where?  Add one pixel to a random line here and there? Add the leftover pixels to the modeline?  That would look bad.

Please think this through before commenting. Any comment that doesn't explicitly state exactly where the leftover pixels shall go is useless.

   Jan D.

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

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> 10 sep 2010 kl. 18:59 skrev Andreas Schwab <schwab@linux-m68k.org>:
>
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>> 
>>> That doesn't matter.  When you say to the window manager to put Eamcs in
>>> fullscreen, the height will be 1024 pixels (if that is what you have).
>>> And there will be a remainder that is not zero.  What do you purpose Emacs
>>> does with this extra space?  Even if we don't have any restrictions, we
>>> can't display a line in this leftover space.
>> 
>> It only requires pixel granularity for the window heights to be able to
>> distribute the leftover space to the windows.
>
> That doesn't make sense. Distribute where?

Just enlarge them, instead of the echo area.  What's so hard to
understand that?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Jan Djärv]

Andreas Schwab skrev 2010-09-11 00.46:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> 10 sep 2010 kl. 18:59 skrev Andreas Schwab<schwab@linux-m68k.org>:
>>
>>> Jan Djärv<jan.h.d@swipnet.se>  writes:
>>>
>>>> That doesn't matter.  When you say to the window manager to put Eamcs in
>>>> fullscreen, the height will be 1024 pixels (if that is what you have).
>>>> And there will be a remainder that is not zero.  What do you purpose Emacs
>>>> does with this extra space?  Even if we don't have any restrictions, we
>>>> can't display a line in this leftover space.
>>>
>>> It only requires pixel granularity for the window heights to be able to
>>> distribute the leftover space to the windows.
>>
>> That doesn't make sense. Distribute where?
>
> Just enlarge them, instead of the echo area.  What's so hard to
> understand that?
>

That is not precise enough.  Enlarge where?  At the top?  At the bottom? Half 
at the top, half at the bottom or some other ratio? Above the mode line? 
Below the mode line?

If we use at the top for example, that would look equally bad IMHO as the 
current situation.  Besides from more or less rewrite the display engine of 
course.

	Jan D.

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

[martin rudalics]

 > That is not precise enough.  Enlarge where?  At the top?  At the bottom?
 > Half at the top, half at the bottom or some other ratio? Above the mode
 > line? Below the mode line?

At the bottom (and at the right), proportionally distributed among
normal windows that appear above (and besides) each other.  But this
can't be done very fast, I'm afraid, since we have to implement
pixel-based window resizing routines and pixel-to-lines/-columns
conversion routines first.  Stephen will explain soonish that XEmacs
has them already ;-)

martin

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

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> That is not precise enough.

Use your imagination.

>  Enlarge where?  At the top?  At the bottom?

Isn't that obvious?

> If we use at the top for example, that would look equally bad IMHO as the
> current situation.

Yes, of course.  Why would you want to do that?

> Besides from more or less rewrite the display engine of course.

Does it?  As I already said, the key point is to be able to specify the
window sizes in pixel granularity, and the display engine can already
handle font sizes that are not a whole mutiple of a character cell.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Jan Djärv]

Andreas Schwab skrev 2010-09-11 10.56:
> Jan Djärv<jan.h.d@swipnet.se>  writes:

>
>> Besides from more or less rewrite the display engine of course.
>
> Does it?  As I already said, the key point is to be able to specify the
> window sizes in pixel granularity, and the display engine can already
> handle font sizes that are not a whole mutiple of a character cell.
>

Using pixel instead of character as a unit of measure has been on the wishlist 
for a long time (in TODO since 2000).  As nobody has so far been able to do it 
makes me think it is quite hard.

	Jan D.

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

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]

On 10/09/10 23:19, Jan Djärv wrote:
>
>
> 10 sep 2010 kl. 18:59 skrev Andreas Schwab<schwab@linux-m68k.org>:
>
>> Jan Djärv<jan.h.d@swipnet.se>  writes:
>>
>>> That doesn't matter.  When you say to the window manager to put Eamcs in
>>> fullscreen, the height will be 1024 pixels (if that is what you have).
>>> And there will be a remainder that is not zero.  What do you purpose Emacs
>>> does with this extra space?  Even if we don't have any restrictions, we
>>> can't display a line in this leftover space.
>>
>> It only requires pixel granularity for the window heights to be able to
>> distribute the leftover space to the windows.
>
> That doesn't make sense. Distribute where?  Add one pixel to a random
 > line here and there? Add the leftover pixels to the modeline?
 > That would look bad.
>

I realise that the display engine is, um, a little involved, so mightn't 
be as easy to actually do as it is to say:

So, Emacs has had proportional fonts and variable size fonts for a 
while, and  has support for displaying only part of a character line, at 
least at the bottom edge of a pane [emacs: window] (not sure about the 
top). It also supports partial character display at the right/left edge 
of the pane.

It's what emacs does right now in other situations - e.g. see the top 
bit of line ";;size14" in attached screenshpt, and also the partial "h" 
at the right end of lines ";;size12" and ";;size13".

Indeed, you'd be wanting the modeline and minibuf to be one whole line 
each (sometimes the minibuf can go multiline, but it'd probably be 
nicest if it sticks to whole lines of characters when it does so where 
possible), but it's pretty unsurprising for a normal multi-line 
scrollable pane to show only part of a line of characters at the end. 
Of course at the same time, snapping to whole characters could be 
considered a feature when resizing, but for a maximized or fullscreen 
window, the ordinary panes seem to me to be aesthetically the least 
worst bit to "give" and go non-integer-character-line-height, avoiding 
the ugly fat border/background shine-through you get around the bottom 
and right of a "maximised" or "fullscreen" window [emacs: frame].

e.g. Noting that the lines AFAIUI can be different pixel heights, with 
the /current/ display engine, I'm just showing them all the same height:

1111111111111111111 ^
1111111111111111111 |
1111111111111111111 |
2222222222222222222 |
2222222222222222222 ordinary emacs pane (3 2/3rd lines)
2222222222222222222 |
3333333333333333333 |
3333333333333333333 |
3333333333333333333 |
4444444444444444444 |
4444444444444444444 v
MMMMMMMMMMMMMMMMMMM ^
MMMMMMMMMMMMMMMMMMM Modeline (1 line)
MMMMMMMMMMMMMMMMMMM v
BBBBBBBBBBBBBBBBBBB ^
BBBBBBBBBBBBBBBBBBB Minibuf (1 line+)
BBBBBBBBBBBBBBBBBBB v


[-- Attachment #2: emacs_partial_lines.png --]
[-- Type: image/png, Size: 35035 bytes --]

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

[Jan Djärv]

David De La Harpe Golden skrev 2010-09-11 02.10:

>
> I realise that the display engine is, um, a little involved, so mightn't be as
> easy to actually do as it is to say:
>
> So, Emacs has had proportional fonts and variable size fonts for a while, and
> has support for displaying only part of a character line, at least at the
> bottom edge of a pane [emacs: window] (not sure about the top). It also
> supports partial character display at the right/left edge of the pane.
>
> It's what emacs does right now in other situations - e.g. see the top bit of
> line ";;size14" in attached screenshpt, and also the partial "h" at the right
> end of lines ";;size12" and ";;size13".
>

Windows use code like this all over the place:

/* Return the frame y-position before which window W ends.
    This includes a mode line, if any.  */

#define WINDOW_BOTTOM_EDGE_Y(W) \
   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
     ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
    + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))


i.e. pixels = lines * font height.  I guess that is what removing the line 
width/height retriction is about.  It is quite a big job and requires more 
insight in to the display engine than I have.  So it is much easier to say 
than to do.

	Jan D.

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

[Eli Zaretskii]

> Date: Sat, 11 Sep 2010 09:50:30 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: "7004@debbugs.gnu.org" <7004@debbugs.gnu.org>
> 
> David De La Harpe Golden skrev 2010-09-11 02.10:
> 
> > has support for displaying only part of a character line, at least at the
> > bottom edge of a pane [emacs: window] (not sure about the top). It also
> > supports partial character display at the right/left edge of the pane.

That's right: Emacs does know how to display a partial line at the
bottom of a window (not at the top, though, IIRC).  The question is
why doesn't it happen in the OP's case.

Perhaps that is some unintended side effect of how a frame is
maximized on X (I cannot reproduce the problem on MS-Windows).  What
happens if the frame is enlarged (e.g., by the mouse) instead?

> Windows use code like this all over the place:
> 
> /* Return the frame y-position before which window W ends.
>     This includes a mode line, if any.  */
> 
> #define WINDOW_BOTTOM_EDGE_Y(W) \
>    (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
>      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
>     + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
> 
> 
> i.e. pixels = lines * font height.

No, your conclusion is incorrect.  See the comment above this macro:
this is the Y pixel coordinate _before_ which the window ends.  If the
last line is only partially visible, the this macro will return a
value that is beyond the actual window display area.

IOW, the fact that Emacs counts pixels in increments of the frame's
default font size does not contradict the ability of displaying
partially visible lines at the window bottom.  When I maximize a frame
on Windows, that is what I get: the last line is only partially
visible.  Why doesn't this happen for the OP on X?

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

[Jan Djärv]

Eli Zaretskii skrev 2010-09-13 14.37:
>> Date: Sat, 11 Sep 2010 09:50:30 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> Cc: "7004@debbugs.gnu.org"<7004@debbugs.gnu.org>
>>
>> David De La Harpe Golden skrev 2010-09-11 02.10:
>>
>>> has support for displaying only part of a character line, at least at the
>>> bottom edge of a pane [emacs: window] (not sure about the top). It also
>>> supports partial character display at the right/left edge of the pane.
>
> That's right: Emacs does know how to display a partial line at the
> bottom of a window (not at the top, though, IIRC).  The question is
> why doesn't it happen in the OP's case.
>
> Perhaps that is some unintended side effect of how a frame is
> maximized on X (I cannot reproduce the problem on MS-Windows).  What
> happens if the frame is enlarged (e.g., by the mouse) instead?

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.

>
>> Windows use code like this all over the place:
>>
>> /* Return the frame y-position before which window W ends.
>>      This includes a mode line, if any.  */
>>
>> #define WINDOW_BOTTOM_EDGE_Y(W) \
>>     (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
>>       ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
>>      + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
>>
>>
>> i.e. pixels = lines * font height.
>
> No, your conclusion is incorrect.  See the comment above this macro:
> this is the Y pixel coordinate _before_ which the window ends.  If the
> last line is only partially visible, the this macro will return a
> value that is beyond the actual window display area.
>
> IOW, the fact that Emacs counts pixels in increments of the frame's
> default font size does not contradict the ability of displaying
> partially visible lines at the window bottom.  When I maximize a frame
> on Windows, that is what I get: the last line is only partially
> visible.  Why doesn't this happen for the OP on X?

I know it can dispay partial lines, info does that on its first page, for 
example, since the title is in a larger font.

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.

I see that W32 does that also, so how can it be different?

	Jan D.

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

[Eli Zaretskii]

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

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

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.

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

[Eli Zaretskii]

> Date: Mon, 13 Sep 2010 22:48:59 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: david@harpegolden.net, 7004@debbugs.gnu.org
> 
> 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.

A window is made an integral multiple of the default font size, yes.
But note the "default" part: some modifications of the default face
can enlarge the screen space a text line takes.  Mode line, having the
`released-button' style, is a prominent example.  But even using a
bold variant of the font enlarges the screen estate a line takes.

Thus, the initial plan is for the window size to be an integral
multiple of the number of text lines, but the actual display does not
necessarily end up that way.

So the display capabilities exist to cope with such a situation.  We
just need a way of enlarging or shrinking a window by pixels.

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

[Jan Djärv]

13 sep 2010 kl. 23:26 skrev Eli Zaretskii <eliz@gnu.org>:

> 
> Thus, the initial plan is for the window size to be an integral
> multiple of the number of text lines, but the actual display does not
> necessarily end up that way.

AFAIK this can not happen by maximizing the frame.

> 
> So the display capabilities exist to cope with such a situation.  We
> just need a way of enlarging or shrinking a window by pixels.

As we don't have that, how can maximizing on w32 do that?

    Jan D.

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

[Jan Djärv]

2010-09-13 23:26, Eli Zaretskii skrev:

> So the display capabilities exist to cope with such a situation.  We
> just need a way of enlarging or shrinking a window by pixels.

We also need a window split/unsplit algorithm that handles leftover pixels.

	Jan D.

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

[martin rudalics]

 > So the display capabilities exist to cope with such a situation.  We
 > just need a way of enlarging or shrinking a window by pixels.

For some value of "just" ;-)

Implementing such a thing is fairly easy modulo the fact that you have
to recursively resize subwindows when changing the size of a frame.  See
the routine change_window_height in XEmacs' window.c for how they do it.

What's also needed:

(1) Pixel-to-character conversion routines.

(2) Pixel-wise mouse tracking and coordinates_in_window stuff.

(3) Pixel-wise window-configurations storing and comparing.

Once done we should then be able to also provide pixel-wise window
scrolling and the ability to start a window at an arbitrary pixel
position (that is, within a character).

martin

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

[Eli Zaretskii]

> Date: Tue, 14 Sep 2010 09:03:13 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: =?UTF-8?B?SmFuIERqw6Rydg==?= <jan.h.d@swipnet.se>, 
>  7004@debbugs.gnu.org
> 
> What's also needed:
> 
> (1) Pixel-to-character conversion routines.
> 
> (2) Pixel-wise mouse tracking and coordinates_in_window stuff.
> 
> (3) Pixel-wise window-configurations storing and comparing.

Maybe I don't understand something, but all these are already in place
(perhaps with the exception of no. 3).  Note that I'm not talking
about being able to set a window height to any number of pixels, just
waste less space in the mini-window, which was the reason for this bug
report.

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

[martin rudalics]

 >> (1) Pixel-to-character conversion routines.
 >>
 >> (2) Pixel-wise mouse tracking and coordinates_in_window stuff.
 >>
 >> (3) Pixel-wise window-configurations storing and comparing.
 >
 > Maybe I don't understand something, but all these are already in place
 > (perhaps with the exception of no. 3).  Note that I'm not talking
 > about being able to set a window height to any number of pixels, just
 > waste less space in the mini-window, ...

You have to be able to set a window height to any number of pixels if
you want to fix the bug.  The case at hand is when Emacs gets a request
from the window manager to set the frame height to a value that is _not_
an integer multiple of Emacs' canonical line height (aka default font
height) of that frame.

IIUC Emacs usually refuses to do that but rounds the height to the
nearest integer multiple of the canonical line height instead.  For the
maximize-frame case, however, Emacs does try to satisfy the request but
adds the remainder of the rounding operation to the minibuffer window
which gives a strange effect because we are accustomed to see the latter
as a one line window without mode-/header-line.

So let's assume that we want to move this remainder to the frame root
window instead.  Now coordinates_in_window from window.c has to

   "Test if the character at column *X, row *Y is within window W.
    If it is not, return ON_NOTHING;
    if it is in the window's text area,
       set *x and *y to its location relative to the upper left corner
          of the window, and
       return ON_TEXT;
    if it is on the window's modeline, return ON_MODE_LINE;
    ..."

but the tests it performs is currently based on things like

WINDOW_BOTTOM_EDGE_Y

which is defined as

#define WINDOW_BOTTOM_EDGE_Y(W) \
   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
     ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
    + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))

that is, an integer multiple of the canonical line height of the frame
of W.  So this does not account for the remainder we want to add and the
result could be that a mouse click in the window text area is recognized
as a click on the window's modeline or even another window.  Obviously,
sampling windows for mouse-autoselection might give strange results as
well.

 > which was the reason for this bug
 > report.

ISTR that Jan and Yamamoto here discussed a similar problem for the
horizontal case, that is, what to do with the remainder on the left or
right of the scrollbar.

martin

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

[Eli Zaretskii]

> Date: Wed, 15 Sep 2010 09:00:25 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, 7004@debbugs.gnu.org
> 
> IIUC Emacs usually [...] rounds the height to the nearest integer
> multiple of the canonical line height instead.

That's not really relevant, since the height includes the tool bar and
the menu bar, whose sizes aren't multiples of the canonical font
height.  So the windows end up with non-integral number of text lines
anyway.

> So let's assume that we want to move this remainder to the frame root
> window instead.  Now coordinates_in_window from window.c has to
> 
>    "Test if the character at column *X, row *Y is within window W.
>     If it is not, return ON_NOTHING;
>     if it is in the window's text area,
>        set *x and *y to its location relative to the upper left corner
>           of the window, and
>        return ON_TEXT;
>     if it is on the window's modeline, return ON_MODE_LINE;
>     ..."
> 
> but the tests it performs is currently based on things like
> 
> WINDOW_BOTTOM_EDGE_Y
> 
> which is defined as
> 
> #define WINDOW_BOTTOM_EDGE_Y(W) \
>    (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
>      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
>     + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
> 
> that is, an integer multiple of the canonical line height of the frame
> of W.  So this does not account for the remainder we want to add and the
> result could be that a mouse click in the window text area is recognized
> as a click on the window's modeline or even another window.  Obviously,
> sampling windows for mouse-autoselection might give strange results as
> well.

If all of this is true, then how do we succeed to display partial
lines with the existing ``pixel-challenged'' display engine?  What am
I missing?

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

[Jan Djärv]

Eli Zaretskii skrev 2010-09-15 21.30:
>> Date: Wed, 15 Sep 2010 09:00:25 +0200
>> From: martin rudalics<rudalics@gmx.at>
>> CC: jan.h.d@swipnet.se, 7004@debbugs.gnu.org
>>
>> IIUC Emacs usually [...] rounds the height to the nearest integer
>> multiple of the canonical line height instead.
>
> That's not really relevant, since the height includes the tool bar and
> the menu bar, whose sizes aren't multiples of the canonical font
> height.  So the windows end up with non-integral number of text lines
> anyway.

The frame may have non-integral height, but the windows don't.  The menu- and 
tool bar heights are calculated separately.  For the built-in tool bar, it 
actually is an integral number of text lines.  Toolkit toolbars don't need to be.

>
> If all of this is true, then how do we succeed to display partial
> lines with the existing ``pixel-challenged'' display engine?  What am
> I missing?

Partial lines are only displayed when one or more lines isn't the size of the 
canonical font size, like the info dir page for example.  But the window as a 
whole is still a multiple of the canonical font size.

Try getting a window size that is a non-integral number of text lines, 
starting with emacs -Q. You can try, but I am confident that can't be done 
without changing the source.

	Jan D.

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

[Eli Zaretskii]

> Date: Wed, 15 Sep 2010 22:45:40 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: martin rudalics <rudalics@gmx.at>, 7004@debbugs.gnu.org
> 
> > If all of this is true, then how do we succeed to display partial
> > lines with the existing ``pixel-challenged'' display engine?  What am
> > I missing?
> 
> Partial lines are only displayed when one or more lines isn't the size of the 
> canonical font size, like the info dir page for example.  But the window as a 
> whole is still a multiple of the canonical font size.

That's true, but it doesn't answer my question.  My question was how
do we manage to display such windows when that happens.  Martin seemed
to be saying that we cannot possibly do that, but in fact we do.

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

[Jan Djärv]

2010-09-16 06:06, Eli Zaretskii skrev:
>> Date: Wed, 15 Sep 2010 22:45:40 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: martin rudalics<rudalics@gmx.at>, 7004@debbugs.gnu.org
>>
>>> If all of this is true, then how do we succeed to display partial
>>> lines with the existing ``pixel-challenged'' display engine?  What am
>>> I missing?
>>
>> Partial lines are only displayed when one or more lines isn't the size of the
>> canonical font size, like the info dir page for example.  But the window as a
>> whole is still a multiple of the canonical font size.
>
> That's true, but it doesn't answer my question.  My question was how
> do we manage to display such windows when that happens.  Martin seemed
> to be saying that we cannot possibly do that, but in fact we do.

I imagine the display engine notice that there are leftover pixels and renders 
another line.  Clipping takes care of the rest.  This is the easy part, I 
guess that is why it has been done.

	Jan D.

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

[martin rudalics]

 >> IIUC Emacs usually [...] rounds the height to the nearest integer
 >> multiple of the canonical line height instead.
 >
 > That's not really relevant, since the height includes the tool bar and
 > the menu bar, whose sizes aren't multiples of the canonical font
 > height.  So the windows end up with non-integral number of text lines
 > anyway.

My frame.h has

/* Number of lines of frame F used for menu bar.
    This is relevant on terminal frames and on
    X Windows when not using the X toolkit.
    These lines are counted in FRAME_LINES.  */
#define FRAME_MENU_BAR_LINES(f) (f)->menu_bar_lines

/* Number of lines of frame F used for the tool-bar.  */
#define FRAME_TOOL_BAR_LINES(f) (f)->tool_bar_lines

so AFAICT these are measured in canonical line heights too.

 > If all of this is true, then how do we succeed to display partial
 > lines with the existing ``pixel-challenged'' display engine?  What am
 > I missing?

The problem I have tried to sketch was not concerned with "how do we
succeed to display ..." but rather with "how to we succeed not to break
the behavior of Emacs when we succeed to display ....".

martin

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

[Jan Djärv]

2010-09-16 09:23, martin rudalics skrev:
>  >> IIUC Emacs usually [...] rounds the height to the nearest integer
>  >> multiple of the canonical line height instead.
>  >
>  > That's not really relevant, since the height includes the tool bar and
>  > the menu bar, whose sizes aren't multiples of the canonical font
>  > height. So the windows end up with non-integral number of text lines
>  > anyway.
>
> My frame.h has
>
> /* Number of lines of frame F used for menu bar.
> This is relevant on terminal frames and on
> X Windows when not using the X toolkit.
> These lines are counted in FRAME_LINES. */
> #define FRAME_MENU_BAR_LINES(f) (f)->menu_bar_lines
>
> /* Number of lines of frame F used for the tool-bar. */
> #define FRAME_TOOL_BAR_LINES(f) (f)->tool_bar_lines
>
> so AFAICT these are measured in canonical line heights too.

Did you read "...  when not using the X toolkit ..."?
These just act as booleans for the non-native case, i.e. anything non-zero 
means on.


	Jan D.

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

[martin rudalics]

 > Did you read "...  when not using the X toolkit ..."?

The doc-string of `frame-pixel-height' tells me that

   In the Gtk+ version of Emacs, it includes only any window (including
   the minibuffer or eacho area), mode line, and header line.  It does
   not include the tool bar or menu bar.

   With the Motif or Lucid toolkits, it also includes the tool bar (but
   not the menu bar).

so this should take care of the remaining cases.  Or am I missing
something?

 > These just act as booleans for the non-native case, i.e. anything
 > non-zero means on.

Maybe that's the reason why my maximized frame starts out as not really
full-screen-height and changes to full-screen height after some dialogue
in the minibuffer-window.  Also, on a tiled screen the Emacs frame is
the only "window" that doesn't entirely fill the space assigned by the
window manager.  On Windows XP with toolbar-mode turned off.

martin

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

[Jan Djärv]

martin rudalics skrev 2010-09-16 14.10:
>  > Did you read "...  when not using the X toolkit ..."?
>
> The doc-string of `frame-pixel-height' tells me that
>
> In the Gtk+ version of Emacs, it includes only any window (including
> the minibuffer or eacho area), mode line, and header line. It does
> not include the tool bar or menu bar.
>
> With the Motif or Lucid toolkits, it also includes the tool bar (but
> not the menu bar).
>
> so this should take care of the remaining cases. Or am I missing
> something?
>

You are not making any sense.  You showed code for FRAME_TOOL/MENU_BAR_LINES
and now you talk about the total frame height.  What "cases" are you referring to?

>  > These just act as booleans for the non-native case, i.e. anything
>  > non-zero means on.
>
> Maybe that's the reason why my maximized frame starts out as not really
> full-screen-height and changes to full-screen height after some dialogue
> in the minibuffer-window. Also, on a tiled screen the Emacs frame is
> the only "window" that doesn't entirely fill the space assigned by the
> window manager. On Windows XP with toolbar-mode turned off.
>

W32 fullscreen behaviour is not relevant at all for X.

	Jan D.

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

[martin rudalics]

 > You are not making any sense.  You showed code for
 > FRAME_TOOL/MENU_BAR_LINES
 > and now you talk about the total frame height.  What "cases" are you
 > referring to?

Well I'm probably too silly to understand that.  I see two basic cases
when trying to calculate the height of windows in change_frame_size:

(1) If toolbar and menubar height are not included in the total height
of the frame, then the root window and the minibuffer window constitute
the total height of the frame.

(2) If toolbar and/or menubar are included in the total height of the
frame, we have two possibilites:

    - The height of any such bar is indicated in lines.  In this case we
      subtract their heights as multiples of canonical line heights.

    - The height of such a bar cannot be calculated in canonical line
      heights.  In this case we must have subtracted their height from
      the total frame height and rounded the remainder in terms of
      canonical line heights _before_ calling change_frame_size so we
      have case (1) again.

In any case the value for the frame root window/minibuffer window
heights is specified by subtracting

#define FRAME_TOP_MARGIN(F) \
      (FRAME_MENU_BAR_LINES (F) + FRAME_TOOL_BAR_LINES (F))

from the line numbers value passed to change_frame_size.  At the time we
do that, the lines of the bar must either not have been reflected in the
argument for change_frame_size or be specified as numbers of lines.

martin

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

[Jan Djärv]

martin rudalics skrev 2010-09-16 18.17:

> - The height of any such bar is indicated in lines. In this case we
> subtract their heights as multiples of canonical line heights.

This is the case for the native menu bar and the native tool bar.

>
> - The height of such a bar cannot be calculated in canonical line
> heights. In this case we must have subtracted their height from
> the total frame height and rounded the remainder in terms of
> canonical line heights _before_ calling change_frame_size so we
> have case (1) again.

This is the case for toolkit menu/tool bar.

>
> In any case the value for the frame root window/minibuffer window
> heights is specified by subtracting
>
> #define FRAME_TOP_MARGIN(F) \
> (FRAME_MENU_BAR_LINES (F) + FRAME_TOOL_BAR_LINES (F))
>
> from the line numbers value passed to change_frame_size. At the time we
> do that, the lines of the bar must either not have been reflected in the
> argument for change_frame_size or be specified as numbers of lines.
>

These values are zero for toolkit menu/tool bar.  They are not the same as the 
frame parameter with similar name.  This is quite obvious when reading the source.

Notice that change_frame_size takes lines/columns as arguments, not pixels, so 
windows can only be sized in those increments.

	Jan D.

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

[martin rudalics]

 > Notice that change_frame_size takes lines/columns as arguments, not
 > pixels, so windows can only be sized in those increments.

Right.  And the proposal of the others boils down to make these pixel
arguments instead.  All I tried to explain was that doing that is fairly
easy because we don't have to bother about the tool and menubars any
more.

The harder part is to handle converse routines like getting the right
window from coordinates or `pos-visible-in-window-p'.  For those we
probably have to store pixel sizes within the window structure to avoid
recalculating sizes, for example, during mouse tracking.  And storing
pixel sizes means we have to update them whenever we resize windows or
the minibuffer.

martin

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

[Jan Djärv]

martin rudalics skrev 2010-09-17 08.34:
>  > Notice that change_frame_size takes lines/columns as arguments, not
>  > pixels, so windows can only be sized in those increments.
>
> Right. And the proposal of the others boils down to make these pixel
> arguments instead. All I tried to explain was that doing that is fairly
> easy because we don't have to bother about the tool and menubars any
> more.
>
> The harder part is to handle converse routines like getting the right
> window from coordinates or `pos-visible-in-window-p'. For those we
> probably have to store pixel sizes within the window structure to avoid
> recalculating sizes, for example, during mouse tracking. And storing
> pixel sizes means we have to update them whenever we resize windows or
> the minibuffer.
>

You also have to fix distribution of window sizes so that in a layout like this:

  -----------------------------
  |               |           |
  |               |           |
  ----------------            |
  |         |     |           |
  |   1     | 2   |     3     |
  |         |     |           |
  -----------------------------

it is 1, 2 and 3 that gets the leftoer pixels. Handling split and delete of 
windows correctly can be hard.

	Jan D.

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

[martin rudalics]

 > You also have to fix distribution of window sizes so that in a layout
 > like this:
 >
 >  -----------------------------
 >  |               |           |
 >  |               |           |
 >  ----------------            |
 >  |         |     |           |
 >  |   1     | 2   |     3     |
 >  |         |     |           |
 >  -----------------------------
 >
 > it is 1, 2 and 3 that gets the leftoer pixels.

Moreover, if 1 or 2 are fixed-size I should give the pixels to the
unnamed window above.

 > Handling split and delete
 > of windows correctly can be hard.

Splitting works line based and the number of lines of a window is not
affected by pixels.  In particular, answering the question whether a
window can be split in the first place is unaffected by pixels.

Now the parent window of the split window has a pixel-height and I have
to reapply the same procedure as for frame resizing recursively to each
of its child windows.

For deleting I add the leftover pixels to the window(s) that get the
lines of the window deleted.

Finally the display-engine must be able to deal with window
top-lines/left-columns and height/width given in pixels.  So the window
structure will probably have four additional slots like pixel-top,
pixel-left, pixel-height, and pixel-width and the display engine must be
able to interpret these.

martin

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

[Stefan Monnier]

>> It's clearly not a feature, so I'd qualify it as a bug.
>> The bug being that Emacs's display code insists on using "character
>> cells" as measuring unit.  Kim had started working on lifting this
>> restriction, but I don't know if anything came out of it,
> That doesn't matter.  When you say to the window manager to put Emacs in
> fullscreen, the height will be 1024 pixels (if that is what you have).
> And there will be a remainder that is not zero.  What do you purpose Emacs
> does with this extra space?

Display more text.  Maybe it will be part of a line, just like is
already the case if you have some fonts that aren't of the same height
as the "cell".
Most of my Elisp windows already end on a partial line, apparently
because the face I use for the docstrings doesn't have the same height
as my default face.  So in my case, the extra pixels might happen to
result in "showing the missing pixels of the last line" in some
cases ;-)


        Stefan
        
        
PS: And I did not say it was an easy thing to do, although back when Kim
mentioned his attempt, I mentioned that one way out would be to always
specify a default face of size 1 pixel (and then play tricks to never
actually use that face, of course).

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

[MON KEY]

,----
| From your picture:
| The height of tool bar + menu bar is 73 pixels.
| Your font height is 17 pixels.
| (1024 - 73)/17 = 55.94117
`----

But, it can also happen when the tool-bar/menu-bar aren't displayed.
Shouldn't the display calculations take this into consideration?

,----
| The remnant (0.94117) is just wasted space, no whole line can be
made to fit in
| to it so it shows up at the botton as unused space. Any window
height that isn't
| an integral of the font height will show like this.
|
| There is no bug here,
`----

It certainly isn't a feature!
I find it can render fullscreen usage aesthetically untenable.

FWIW I've had to tweak X to get (somewhat) satisfactory fullscreen behaviour.

--
/s_P\

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

[Jan Djärv]

2010-09-10 15:40, MON KEY skrev:
> ,----
> | From your picture:
> | The height of tool bar + menu bar is 73 pixels.
> | Your font height is 17 pixels.
> | (1024 - 73)/17 = 55.94117
> `----
>
> But, it can also happen when the tool-bar/menu-bar aren't displayed.
> Shouldn't the display calculations take this into consideration?
>

How?  Adjust the resolution?  Wasted space is wasted space.  What can we do 
with it?  Select a smaller font for that line?

	Jan D.

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

[MON KEY]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Fri, Sep 10, 2010 at 12:06 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 2010-09-10 15:40, MON KEY skrev:
>
> How?

When menu-bar/tool-bar aren't displayed don't calculate their size
when determining the size of the mini-buffer.

> Adjust the resolution?

I doubt that it is TRT, but maybe adjusting the size of
non-mini-buffer window would be better than spilling the diff off into
the mini-buffer

> Wasted space is wasted space.  What can we do with it?

Indeed, so why count it?

>  Select a smaller font for that line?
For the calculated difference ratio?
Why, do that when here is no "line" to which the user could insert
text/objects to anyways.

Or, maybe I am misunderstanding the cause of the problem?

I've attached two .png screencaptures showing my Emac with and without menu-bar.

>
>        Jan D.
>

--
/s_P\

[-- Attachment #2: screen-w-menu-bar.png --]
[-- Type: image/png, Size: 29391 bytes --]

[-- Attachment #3: screen-w-out-menu-bar.png --]
[-- Type: image/png, Size: 25528 bytes --]

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

[Dani Moncayo]

Hi there,

One question: This bug was closed by Jan, claiming there was no bug
(see mail bellow), but after that Stefan said it was, and there was a
debate about how to solve it.

So, given that the problem is still unsolved, shouldn't it be kept
open? (I see it as "resolved" in the bug tracker)


On Fri, Sep 10, 2010 at 11:00, GNU bug Tracking System
<help-debbugs@gnu.org> wrote:
> Your bug report
>
> #7004: 23.2; In fullscreen mode, the echo area takes too much vertical space
>
> which was filed against the emacs package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 7004@debbugs.gnu.org.
>
> --
> 7004: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7004
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: "Jan Djärv" <jan.h.d@swipnet.se>
> To: Dani Moncayo <dmoncayo@gmail.com>
> Date: Fri, 10 Sep 2010 11:01:23 +0200
> Subject: Re: bug#7004: 23.2; In fullscreen mode, the echo area takes too much vertical space
> Please do not post in html.
>
> From your picture:
> The height of tool bar + menu bar is 73 pixels.
> Your font height is 17 pixels.
>
> (1024 - 73)/17 = 55.94117
>
> The remnant (0.94117) is just wasted space, no whole line can be made to fit in to it so it shows up at the botton as unused space.  Any window height that isn't an integral of the font height will show like this.
>
> There is no bug here,
>
>        Jan D.
>


--
Dani Moncayo



-- 
Dani Moncayo

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

[Dani Moncayo]

This bug was closed prematurely, as I said in the last post in this
bug report (date 2010-12-08).

I asked to reopen it, but no one replied, so I've just done it myself.
I hope doing so it's OK.

-- 
Dani Moncayo

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

[Tassilo Horn]

Dani Moncayo <dmoncayo@gmail.com> writes:

Hi Dani,

> When I put Emacs in fullscreen mode, it seems to me that the last line
> (echo area/minibuffer) takes too much, unnecessary vertical space.

What would you expect instead?

I think, this is not an emacs problem, but it has something to do with
window managers.  I'm no expert in Emacs' frame stuff or window
managers, but I think, it is something along this.

Emacs issues size hints to the window manager, which tells it the width
and height of how emacs wants to be painted.  These sizes are exactly
divisible by the number of lines/columns emacs should display, which
depends on font size and stuff like that.

If the window manager honores these hints, then is it likely that a
fully maximized emacs frame (or a fullscreen frame) does not fill the
whole screen, but there is a gap of at most one line/column size in
pixels minus one pixel.

Because that somehow looks ugly, many window managers decide not to
honor hints at least for fullscreen/maximized windows.  They stretch the
window to the exact display size, and then you have the effect you
describe.  So you don't see one unnecessary line, but only some percent
of a unnecessary line.  Even if it is 99%, it's still no full line.
IMHO, that's much better than a gap.

I know that at least there was or is a problem with emacs built with GTK
in conjunction with the KDE window manager.  There, maximizing emacs did
honor the hints, and you got the gaps.  But the real problem was that
the window manager would not recognize emacs as a maximized window in
that case.

Bye,
Tassilo

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

[Dani Moncayo]

On Thu, Mar 17, 2011 at 13:08, Tassilo Horn <tassilo@member.fsf.org> wrote:
>> When I put Emacs in fullscreen mode, it seems to me that the last line
>> (echo area/minibuffer) takes too much, unnecessary vertical space.
>
> What would you expect instead?

In short, I would expect Emacs to use _all_ the available space to
display content (as pointed out by Stefan previously).

I will try to develop this idea a little further:

0.- A bit of nomenclature, to avoid misunderstanding (disclaimer: I've
not found better names after a while of thinking! :) ):
0.1.- Let's call "GWindow" (after "graphical window") to a
"window-manager window", i.e., what is normally called "window" in the
context of a window manager or desktop environment.
0.2.- Let's call "ClientArea" to the rectangle of the GWindow intended
for application-specific drawing, i.e., the GWindow excluding title
bar, tool bars, menú bars, graphical borders, etc.

1.- When using Emacs in graphical mode, the user should be able to set
each Emacs' GWindow to any* desired _pixel_ size, regardless of
whether it is maximized or not.
(*): Maybe imposing lower limits.

2.- Given the desired (user-imposed) total size of the GWindow, Emacs
should ask the window manager for the size of its ClientArea (height
and width).

3.- Compute the total "remaining height", i.e., the leftover height if
only _complete_ lines were displayed in each currently visible window
(of course taking into account the font(s) associated with the text to
be displayed).

4.- Compute the "remaining width" analogously (i.e. repeat previous
step, replacing "height" with "width" and "lines" with "columns").

5.- At this point, Emacs could finally do the drawing this way:
5.1- Distribute the total remaining height among the currently visible
windows, in the form of partial lines displayed at the bottom of each
window. (This "distribution" may not be trivial, as pointed out
already in this thread...)
5.2- Similarly, distribute the total remaining width in the form of
partial columns displayed at the right of each window.


> Emacs issues size hints to the window manager, which tells it the width
> and height of how emacs wants to be painted.  These sizes are exactly
> divisible by the number of lines/columns emacs should display, which
> depends on font size and stuff like that.

With my previous approach, there would be no need for such hints.
Emacs should be able to adapt itself to any pixel size imposed by the
window manager (which in turn obeys to the user).


-- 
Dani Moncayo

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

[Tassilo Horn]

Dani Moncayo <dmoncayo@gmail.com> writes:

Hi Dani,

>> Emacs issues size hints to the window manager, which tells it the
>> width and height of how emacs wants to be painted.  These sizes are
>> exactly divisible by the number of lines/columns emacs should
>> display, which depends on font size and stuff like that.
>
> With my previous approach, there would be no need for such hints.

Window manager hints are nothing special about emacs:

  http://standards.freedesktop.org/wm-spec/wm-spec-latest.html

> Emacs should be able to adapt itself to any pixel size imposed by the
> window manager (which in turn obeys to the user).

I don't see what would be the benefit of your approach.  What's the
value of being able to see half or quarter lines/columns?

Well, there's one case, where I can see it being useful, and that's when
images are shown in a buffer that also contains text, because images
occupy exactly one column/line, just like a huge glyph.  In contrast to
browsers, emacs doesn't use standard GTK or Qt canvas, where you get
that for free, but underly other restrictions which are more crucial to
emacs.

Bye,
Tassilo

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

[Dani Moncayo]

Hi, Tassilo


On Thu, Mar 17, 2011 at 21:31, Tassilo Horn <tassilo@member.fsf.org> wrote:
>
> Window manager hints are nothing special about emacs:
>

I didn't say the contrary. What I wanted to say is that (with my
approach) Emacs would have no need to tell the window manager the size
it wants. Conversely, Emacs would ask to the window manager the size
of the "client area", in order to organize the layout and draw the
frame inside it.

>
> I don't see what would be the benefit of your approach.  What's the
> value of being able to see half or quarter lines/columns?
>

Well, my approach is intended especially for situations in which the
GWindow is maximized or fullscreen. But maybe doesn't make much sense
when the GWindow has an arbitrary size. In such case, maybe it would
be better to resize a bit the GWindow (via hints, as you said), so
that no partial lines/columns are shown.

I don't feel very strongly about it. Indeed, sometimes I think that a
simpler solution would be to distribute the remnant space evenly
between top/bottom and left/right extremes of the "client area", so
that the emacs frame appears centered inside it.


Bye,

--
Dani Moncayo

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

[Tassilo Horn]

Dani Moncayo <dmoncayo@gmail.com> writes:

Hi Dani,

> I don't feel very strongly about it. Indeed, sometimes I think that a
> simpler solution would be to distribute the remnant space evenly
> between top/bottom and left/right extremes of the "client area", so
> that the emacs frame appears centered inside it.

I think, there was some window manager that can do exactly that.  It
might be XMonad, or awesome.  Not sure anymore, but at least it was one
of the tiling ones.

Bye,
Tassilo

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

[Jan Djärv]

Dani Moncayo skrev 2011-03-17 19.43:

> 5.- At this point, Emacs could finally do the drawing this way:
> 5.1- Distribute the total remaining height among the currently visible
> windows, in the form of partial lines displayed at the bottom of each
> window. (This "distribution" may not be trivial, as pointed out
> already in this thread...)
> 5.2- Similarly, distribute the total remaining width in the form of
> partial columns displayed at the right of each window.

Some of us thinks this is so ugly and really only ever want complete 
lines/columns to be displayed.  It is so much easier to read then.

> With my previous approach, there would be no need for such hints.
> Emacs should be able to adapt itself to any pixel size imposed by the
> window manager (which in turn obeys to the user).
>

The hints aren't there just to impose size, they are there also so that the 
window manager can tell the users lines and columns when an emacs frame is 
resized, instead of pixel.  Changing this is out of the question.

	Jan D.

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

[Dani Moncayo]

On Fri, Mar 18, 2011 at 07:21, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> 5.- At this point, Emacs could finally do the drawing this way:
>> 5.1- Distribute the total remaining height among the currently visible
>> windows, in the form of partial lines displayed at the bottom of each
>> window. (This "distribution" may not be trivial, as pointed out
>> already in this thread...)
>> 5.2- Similarly, distribute the total remaining width in the form of
>> partial columns displayed at the right of each window.
>
> Some of us thinks this is so ugly and really only ever want complete
> lines/columns to be displayed.  It is so much easier to read then.
>

Fair enough. I was trying to make the most of the available space to
display content. But that space is small (less than a line/column), so
that wasting it in partial lines/columns doesn't worth it.

But the actual situation (in fullscreen/maximized mode, put all
remnant space at the bottom) doesn't look fine either.


-- 
Dani Moncayo

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

[Dani Moncayo]

On Fri, Mar 18, 2011 at 08:30, Dani Moncayo <dmoncayo@gmail.com> wrote:
>
> But the actual situation (in fullscreen/maximized mode, put all
          ^^^^^^

I meant "current". Sorry.

-- 
Dani Moncayo

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

[Dani Moncayo]

Hi Jan,

The problem reported in this thread is a minor one, of course, but a
related problem is a bit annoying:

When I maximize my Emacs frame (on Windows), after a while (switching
between applications) it ends up a bit resized, so that the spare
space is removed at the expense of having a not-totally-maximized
frame.

I propose the following to resolve this problem and the original one:
When a frame is maximized (or fullscreen), distribute the spare space
evenly among the top/bottom and left/right side.

WDYT?

-- 
Dani Moncayo

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

[Jan Djärv]

Dani Moncayo skrev 2011-09-05 12:32:
> Hi Jan,
>
> The problem reported in this thread is a minor one, of course, but a
> related problem is a bit annoying:
>
> When I maximize my Emacs frame (on Windows), after a while (switching
> between applications) it ends up a bit resized, so that the spare
> space is removed at the expense of having a not-totally-maximized
> frame.
>
> I propose the following to resolve this problem and the original one:
> When a frame is maximized (or fullscreen), distribute the spare space
> evenly among the top/bottom and left/right side.
>
> WDYT?
>

It is easy to say but very hard to do.  You need to modify Emacs 
redisplay/window code and also each of the ports (X11, Xt, Gtk+, NS, Windows) 
have code for this that needs to be modified.
What happens on Windows is nothing I know about.

The solution must be to add something that takes up slack that isn't an Emacs 
window.  On OSX Lion this happens automatically when Emacs is fullscreen (in 
my own modified version).  A black strip appears under the toolbar.

But we are in feature freeze, so this is nothing I think about.

	Jan D.