bug#12419: Mouse click changes layout

[Eli Zaretskii <eliz@gnu.org>]

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

Sorry, I don't understand what you mean by "drawing over a previous
column/row".  Which "previous" column/row are we talking about?

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

A window must always start with a fully-visible line (unless it's the
only line), so in that sense a window always starts at an integral
number of lines.  But it doesn't have to _end_ with a fully-visible
line.

Does this explain why the above is not a problem?

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

Can't happen: a window that displays 5.5 lines must have 6 lines, or
else the glyphs for the last half-line will have no place in the glyph
matrix.

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

It's up to us.  The easiest (and also the least surprising, IMO) would
be to resize from (5.5, 5.5) to (6.5, 4.5), i.e. by one full line.

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

I think pos-visible-in-window-p is what you need.