bug#24030: 25.0.95; mouse-drag-region regression

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex <agrambot@gmail.com>
> Date: Tue, 19 Jul 2016 16:11:48 -0600
> 
> If you attempt to create a region by dragging the mouse in a
> never-before-focused window, then the region isn't shown until letting
> go of the mouse button.

More accurately, it's not the window that was never the selected one,
it's the buffer that is displayed in it.  To see that, after selecting
the window, switch back to the other window (showing *scratch* in the
recipe), then type the same C-h f command again, and you will see the
problem, even though the window was already selected.  That's because
each C-h f erases and fills up the *Help* buffer again.

AFAICT, the root cause is the fact that region-active-p returns nil
under the specific circumstances of the recipe.  Why it returns nil is
less clear; AFAICS it's because mark-active is nil after the first
click of the mouse, when redisplay--update-region-highlight is called
from the display engine.  And mark-active is nil because some code
that I was unable to track down sets deactivate-mark to non-nil, so
the command loop deactivates the mark.

I hope someone else will be able to pick up where I left off, and find
the offending code.

> This doesn't work in the pretest, but it did in Emacs 24.5.

Right.

Btw, debugging such core features which are implemented in Lisp that
is called from the display engine is a nightmare, because there's no
easy way of displaying values of key Lisp variables, for the obvious
reasons.  My conclusion is that such refactoring brings significant
maintenance headaches, which need to be carefully considered as part
of similar decisions in the future.  If someone knows of handy
techniques to make this easier, I'd love to hear about them.

Thanks.