bug#12419: Mouse click changes layout

[martin rudalics]

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