bug#12419: Mouse click changes layout

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 14 Sep 2012 11:00:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 12419@debbugs.gnu.org
> 
>  > I guess the annoying thing is that the resizing happens on mouse-down
>  > and side-ways scrolling on mouse-drag, i.e. in the middle of my
>  > operation.  If it were deferred till mouse-up (or till I drag to outside
>  > of the window to force scrolling), then it would be consistent with
>  > regard to where I clicked.
> 
> You could try to inject some code at the beginning of
> `window--resize-root-window-vertically' that writes a backtrace into a
> buffer.  This way we could get some information about the kind of
> mouse-event that caused the resizing.

There's no need for anything that fancy, AFAICS.  Here's the recipe I
used:

  emacs -Q
  C-x 4 f xdisp.c RET
  C-x o
  M->
  (message (make-string 380 ?a))
  C-x C-e

The "C-x C-e" should be typed with point after the last expression
that calls 'message'.

Note that evaluating that expression raises the mode line of both the
lower and the upper windows.  That didn't happen in Emacs 23.3, where
it would only affect the mode line (and the lower part) of the _lower_
window that shows xdisp.c.

Now move the mouse pointer to some place in the lower window, and
press and hold the left mouse button.  You will see the message in the
echo area disappear, and the mode line of *scratch* move down, thus
causing scroll of the text in the xdisp.c window below it.  Again,
this doesn't happen in Emacs 23.3.

The same effect happens if, instead of clicking the mouse, you press
some key.  IOW, this is not limited to mouse clicks; instead, the
reason is the removal of the message from the echo area, which is
normal and happens upon any input.

My conclusion from the above experiment is that the reason for the
problem is that we somehow redistribute the screen real estate between
the windows when the echo area grows/shrinks.  Any pointers to where
this happens are welcome.