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