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

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex <agrambot@gmail.com>
> Cc: 24030@debbugs.gnu.org
> Date: Fri, 22 Jul 2016 00:09:22 -0600
> 
> > 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.
> 
> It appears that it's somewhere within select-window or something it
> calls. After posn-set-point calls select-window in 24.5, deactivate-mark
> is nil -- but it's t in 25.1.
> 
> #+BEGIN_SRC elisp
> (defun test ()
>   (message "before: %s" deactivate-mark)
>   (select-window (cadr (window-list)))
>   (message "after: %s" deactivate-mark))
> #+END_SRC
> 
> In the case where the target window contains the new help buffer,
> deactivate-mark will be nil in 24.5 and t in 25.1.

Thanks.

The reason for the above is that in Emacs 25 deactivate-mark was made
a variable that becomes buffer-local when set.  And inserting text
into a buffer, which happens when describe-function inserts the
documentation into *Help*, was made to set the this variable in a way
that creates a buffer-local binding for it.  That is why select-window
gives deactivate-mark a non-nil value: select-window makes the
window's buffer the current one, which assigns buffer-local values to
all of it variables, including deactivate-mark.  Then this
buffer-local value is being examined by mouse-drag-region.

I think the problem is that the command loop fails to reset the
buffer-local value of this variable, so we must add something to
keyboard.c, where the global value is reset after each command.

I'm CC'ing Stefan, who made the above-mentioned changes, in the hope
that he will have some ideas for how to fix this regression.