bug#12419: Mouse click changes layout

[martin rudalics <rudalics@gmx.at>]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

 > Ahem, not so sure what you'd want here.  But playing with your
 >
 >  >   emacs -Q
 >  >   (message (make-string 1000 ?a))
 >  >   C-x C-e
 >
 > example, which btw. give me only 8 lines, whit the initial quote out of
 > sight, you can easily reproduce this:
 >
 > Split *scratch* horizontally

... vertically (the new window is below the old one) ...

 > and then click on the 1 of 1000.

... in the new, lower window.

 > The
 > minibuffer shrinks, the 1 is blinking, but the mouse is no over the n of
 > notes, which slid down.  When letting go, the n blinks and all up to
 > before 1000 is marked.

I can see that.

 > Independently of resizing, something similar happens for sideways
 > scrolling:  Split *scratch* vertically, click on the v of visit,

What is 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'd expect both cases to consistently do something only when I release
 > the mouse, or when I drag to outside the window to force scrolling.

Can you try the attached patch?

Thanks, martin

[-- Attachment #2: resize-root-window-vertically.diff --]
[-- Type: text/plain, Size: 2560 bytes --]

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-09-16 04:52:38 +0000
+++ lisp/window.el	2012-09-16 17:38:02 +0000
@@ -2394,27 +2394,32 @@
 This function is only called by the minibuffer window resizing
 routines.  It resizes windows proportionally and never deletes
 any windows."
-  (when (numberp delta)
-    (let (ignore)
-      (cond
-       ((< delta 0)
-	(setq delta (window-sizable window delta)))
-       ((> delta 0)
-	(unless (window-sizable window delta)
-	  (setq ignore t))))
-
-      (window--resize-reset (window-frame window))
-      ;; Ideally, we would resize just the last window in a combination
-      ;; but that's not feasible for the following reason: If we grow
-      ;; the minibuffer window and the last window cannot be shrunk any
-      ;; more, we shrink another window instead.  But if we then shrink
-      ;; the minibuffer window again, the last window might get enlarged
-      ;; and the state after shrinking is not the state before growing.
-      ;; So, in practice, we'd need a history variable to record how to
-      ;; proceed.  But I'm not sure how such a variable could work with
-      ;; repeated minibuffer window growing steps.
-      (window--resize-this-window window delta nil ignore t)
-      delta)))
+  (let (ignore)
+    (cond
+     ((not (numberp delta))
+      (setq delta 0))
+     ((zerop delta))
+     ((< delta 0)
+      (setq delta (window-sizable window delta))
+      (window--resize-reset (window-frame window))
+      ;; When shrinking the root window, emulate an edge drag in order
+      ;; to not resize other windows if we can avoid it (Bug#12419).
+      (window--resize-this-window
+       window delta nil ignore t 'before
+       (+ (window-top-line window) (window-total-size window)))
+      ;; Don't record new normal sizes to make sure that shrinking back
+      ;; proportionally works as intended.
+      (walk-window-tree
+       (lambda (window) (set-window-new-normal window 'ignore))))
+     ((> delta 0)
+      (window--resize-reset (window-frame window))
+      (unless (window-sizable window delta)
+	(setq ignore t))
+      ;; When growing the root window, resize proportionally.  This
+      ;; should give windows back their original sizes (hopefully).
+      (window--resize-this-window window delta nil ignore t)))
+     ;; Return the possibly adjusted DELTA.
+     delta))
 
 (defun adjust-window-trailing-edge (window delta &optional horizontal)
   "Move WINDOW's bottom edge by DELTA lines.