> However my first informatics lesson the professor told us: the most
> common bug is being off by one. That is alas still the case with your
> patch: After C-x 2 the lower window is one row higher than the upper
> one. After our little experiment, it's the other way round, with this
> result: When letting go of the mouse, I still marked to the line above,
> which is now in the position of my mouse-down event. Sounds like an
> integer division rounding problem, though I don't see such a thing in
> your patch. If both windows together have an even number of rows (by
> resizing the frame) it's fine.
You should get a similar behavior if you have a root window with an odd
number of lines, split that window via C-x 2, shrink the frame by one
line, and enlarge it again by one line: The upper window has stolen one
line from the lower one. As a matter of fact, this is not an off-by-one
error but more deeply rooted in the history of Emacs' window handling.
You can skip the following explanation if you want.
Beginning with Emacs 24.1, windows have a normal height (a floating
point number) which is the fraction of their ideal height wrt to their
parent. When you do C-x 2 the normal height of both emanating windows
is 0.5. However, when the original window has an odd number of lines,
I have to give the lower window the one remaining line in order to be
consistent with the traditional splitting behavior. This means that,
if the original window has 11 lines, the upper window gets 5 and the
lower window gets 6 lines.
If I now enlarge the parent window to 22 lines, the upper window gets
11 (and not 10) lines and the lower window 11 (and not 12 lines).
Sizing back the parent to 11 lines should restore the initial state
but it doesn't because I resize windows in the "opposite" direction
(from top to bottom/from left to right) which preferably gives
to/steals from the topmost/leftmost window.
So I have to fix this regardless of the topic we're discussing here.
> If however I split either of the two windows again (even the top one,
> which is out of reach of the resizing echo area) the disturbing new
> before-your-patch behaviour comes back.
I suppose you should try again. If I split the top window, only the
bottom window resizes and I can't observe what you observe here. If I
make a new bottom window instead, the line where `point' appears in that
window moves to the top of the window and I can observe the behavior.
However, I don't see any difference wrt Emacs 23 which means I do not
see a "disturbing new" before-my-patch behavior. If you nevertheless
do, please give me a detailed step-by-step scenario I can repeat here.
>> The second scenario you sketched is
[...]
> The point is moving the mouse over to the i, which causes the 1st
> scroll, and then letting go, which causes the scrolled region to be
> marked, plus it causes a 2nd scroll by the same amount. So the point is
> now far from the highlighted part. I guess this comes from a different
> code location. Only the user experience feels to me like both cases
> should be consistent with one another.
OK. I see something in this regard. But Emacs 23 seems to behave in
exactly the same way. Or do you see a difference?