bug#12419: Mouse click changes layout

[martin rudalics <rudalics@gmx.at>]

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

Obviously, we can replace this restriction by a pixel specified one and
things become probably much simpler.  In any case, these routines have
to be rewritten.  I can't tell how this will affect the remaining code
(large parts of which rely on `window--resize-child-windows').

 > Why?  Emacs doesn't promise to have the last line visible even now, if
 > the window has variable size fonts.  What we currently do promise
 > (IIUC) is to have each window's height an integral multiple of the
 > default face's height.  But if the window shows no characters with the
 > default face, that contract is irrelevant anyway.

It's not me you have to convince here ;-)

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

 > 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.  And likely, window resizing will get inconsistent over time.
Give it a try.  Have you ever looked at the routines XEmacs uses for
handling frame/window pixel sizes?  There's quite a lot of them.

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

martin