bug#12419: Mouse click changes layout

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 25 Sep 2012 16:12:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  >>  > Where in the code or the infrastructure do we enforce an integral
>  >>  > number of lines in a window?
>  >>
>  >> All over the window handling code, presently.
>  >
>  > Can you humor me with a typical example, please?
> 
> The central routine is `window--resize-child-windows'.  But
> `balance-windows-2' and `fit-window-to-buffer' are typical too.  All
> these go a long way to meet a self-imposed restriction specified in
> lines (and columns) by adding lines one-by-one to some window.

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; what should happen
instead is that (in a GUI session) an N-line window is always split
into 2 ⌈N/2⌉-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.

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.

>  >> So even if we manage to provide really maximized frames, the window
>  >> handling code will have to show most windows with fully visible
>  >> lines.
>  >
>  > See above: you cannot guarantee that.
> 
> My experience tells me that people using the default face and only that
> will ask for it.  Let's hope I'm wrong.

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.

>  > Do we really need such a change?  What damage could be caused by
>  > accepting a window size in integral lines, but producing a window that
>  > is slightly larger or smaller?  Again, this happens today already as
>  > long as non-default faces are displayed in the window.
> 
> Probably not much.  Parts of the mouse code might report incongruent
> results.

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

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

Again, please elaborate.

>  >> And I suppose that we want a function that calculates the number of
>  >> pixels between two buffer positions
>  >
>  > Doesn't pos-visible-in-window-p fit the bill already?
> 
> 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.