bug#12419: Mouse click changes layout

[martin rudalics <rudalics@gmx.at>]

 >> Can you try the attached patch?
 >
 > I now did, but in neither split direction anything seems to have changed
 > from what I described before.

Let's look at your first scenario with emacs -Q: Do

C-x 2

C-x o

and in the lower window insert the form

(message (make-string 1000 ?a))

so the buffer *scratch* now contains this text:


;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

(message (make-string 1000 ?a))


Now evaluate the form inserted - the minibuffer window resizes and the
divider line between the upper and lower normal window moves up.  Still
in the lower window press the left mouse button down (but don't release
it) with the mouse pointer on the "1" of the "1000".  Now release the
left mouse button and the region starting with the word "notes" up to
the space before "1000" gets higlighted.

This is the behavior I observe with an unpatched Emacs trunk.  With the
patch, the divider line between the upper and lower window does not move
and there's no region highlighting when I release the mouse button.


The second scenario you sketched is

 > Independently of resizing, something similar happens for sideways
 > scrolling: Split *scratch* vertically, click on the v of visit, nothing
 > happens (that's where it dffers).  But then move the mouse 1 char right,
 > this triggers a sideways scroll.  The mouse is now over the e of file.
 > When letting go, it marks "visit that fil" but worse, it scrolls yet
 > again by the same amount, so that the mouse is now at the end of the
 > line, far from the text it marked.

I suppose what you mean here with emacs -Q is:

C-x 3

Now if I click in any of the two windows on the "v" of the word "visit",
I get the same sideways scroll behavior with my Emacs 23.3, Emacs 24.1
and the current trunk regardless of how long I keep the button pressed.

martin