bug#12419: Mouse click changes layout

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 26 Sep 2012 14:43:22 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  > Sorry, I don't understand what you mean by "drawing over a previous
>  > column/row".  Which "previous" column/row are we talking about?
> 
> For example, when we draw the mode-line of a window: Do we first clip
> the glyphs on the bottom of the last proper line of the window or do we
> draw them unclipped and afterwards draw the mode-line on top of it so it
> obscures the lower part of the window line?

It's the other way around: first the window is cleared, then we draw
the mode line, and only then the window text.  So the last line is
already drawn only partially to begin with (I believe this is done by
the display back-end, in *term.c, by clipping the drawn glyphs to the
dimensions of the text area, but I'm not an expert on these back-ends).

>  >> 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.
> 
> Let's say the TTY equivalent of the upper window would display 5 lines.

And the lower one 6, OK.

>  >> 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.
> 
> In this case the TTY equivalent would display (6, 5) lines.

Yes.  Is that a problem?  pos-visible-in-window-p can still tell
whether the resize reached its goal of exposing the text you want, no?

>  >> 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.
> 
> Currently it loops calling `pos-visible-in-window-p' until the position
> is visible.  How avoid that loop?

I think the loop isn't needed for the application you have in mind.
But if it is, can you show a concrete use case where just using that
function gives bad results for measuring pixel distance between buffer
positions?