bug#12419: Mouse click changes layout

[martin rudalics <rudalics@gmx.at>]

 > That's true, but I don't think this is relevant to the issue.  What
 > _is_ relevant is that these functions divide an odd number N of lines
 > in the window being split into an ⌈N/2⌉-line window and an ⌊N/2⌋-line
 > window, like an 11-line window being split into 6 and 5 lines.  _This_
 > is the self-imposed restriction we need to remove;

Agreed.

 > what should happen
 > instead is that (in a GUI session) an N-line window is always split
 > into 2 ⌈N/2⌉-line windows.

... which can be partially truncated so we will have 2 ⌊N/2⌋-full-line
windows.

 > The number of lines in a window is needed for the display engine to
 > allocate glyph matrices required to display the window.  Having the
 > size of each child window at ⌈N/2⌉ will ensure the right dimensions of
 > the glyph matrices, because even a partially-visible line needs a row
 > in the matrix.  There are no other restrictions in the display engine,
 > AFAIK, that require an integral number of lines to be displayed in a
 > window.

I suppose so since otherwise we would have seen bugs earlier.  A silly
question: Does the `display-engine' draw over a previous column/row or
does it clip it?

 > Note that on a TTY, there are no partially-visible lines, and the
 > window glyph matrices are just parts of a single frame-based matrix,
 > so the current way of dividing N lines should be kept for TTY.

OK

 > It happens already today: with some customizations of frame parameters
 > the last line of a single-window frame is not fully visible already,
 > albeit only slightly so.  This happens since Emacs 21.1 introduced the
 > special faces of the mode line, which take a few more pixels than a
 > normal text line in the default face.  E.g., I have this in my .emacs:
 >
 >   (add-to-list 'default-frame-alist '(font . "-outline-Courier New-normal-r-normal-normal-15-112-96-96-c-90-iso8859-1"))
 >   (add-to-list 'default-frame-alist '(height . 50))
 >
 > With these customizations, Emacs doesn't let me put the cursor on the
 > last line: it scrolls the window, because the last line is not
 > fully-visible.  I don't think we've heard any complaints about this.

I have

  '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))

which does similar things.  In addition I use maximized frames which
sometimes cover my entire display and sometimes don't.  I suppose many
people have learned to live with such shortcomings when they have
customizations.  But what about people who did not customize anything and
expect the old "integral lines" behavior.

 > Sorry, I don't follow: which mouse code did you have in mind, and why
 > would it report incongruent results?

Take make_lispy_position.  It has

       /* Pixel coordinates relative to the window corner.  */
       int wx = XINT (x) - WINDOW_LEFT_EDGE_X (w);
       int wy = XINT (y) - WINDOW_TOP_EDGE_Y (w);

where

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

Now if the lower window of a two windows frame does not start at an
integral number of lines this will not DTRT.  Or am I missing something?

 >> And likely, window resizing will get inconsistent over time.
 >
 > Again, please elaborate.

Consider a two window frame, the upper window has 5 lines the lower
window has 6 lines but in fact both are shown with 5.5 lines.  Now I
enlarge the upper window by one line.  Currently this makes a 6 to 5
lines frame.  Would it make a 6.5 to 4.5 frame with the new code or a 6
to 5 lines frame?

 >> Have you looked at the loop at the end of `fit-window-to-buffer'?  It's
 >> apparently needed because `count-screen-lines' doesn't return a value
 >> that's good enough there.
 >
 > fit-window-to-buffer tries to avoid partially-visible lines.  That's
 > not always required, or maybe I don't understand why you need a
 > function that calculates the number of pixels between two positions.

For implementing something like `count-screen-lines-to-pixels' and get
rid of that crazy loop where we calculate `pos-visible-in-window-p' and
resize the window.

martin