bug#12419: Mouse click changes layout

[martin rudalics]

> 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