GNU bug report logs - #24030
25.0.95; mouse-drag-region regression

Previous Next

Full log

Message #26 received at 24030 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 24030 <at> debbugs.gnu.org, agrambot <at> gmail.com
Subject: Re: bug#24030: 25.0.95; mouse-drag-region regression
Date: Sun, 24 Jul 2016 17:12:16 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: agrambot <at> gmail.com,  24030 <at> debbugs.gnu.org
> Date: Sat, 23 Jul 2016 17:16:37 -0400
> 
> > 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.
> 
> Indeed, this is a problem here because of have a "stale" setting of
> deactivate-mark.
> 
> Maybe something like the patch below will do?

It didn't solve the problem here.  Did it work for you?

> Another option is to make the deactivate-mark function reset
> deactivate-mark to nil (which would seem to make a lot of sense in
> itself) and then to call deactivate-mark at that point or to move the
> earlier deactivate-mark to after mouse-set-point.

Neither of these seems to solve the problem.

What do you think about the alternative patch below?  It does seem to
solve the problem here.

> Of course, maybe there should be a more thorough handling of stale
> deactivate-mark settings.  IOW change all places that set
> deactivate-mark to non-nil so they also record the affected buffer and
> then change the command loop so that it calls deactivate-mark in all
> those buffers where deactivate-mark was set as non-nil.

I envision complications with this when recursive-edit is used.

> > How did it become stale, though?  It was supposed to be reset by the
> > command loop when the "C-h f" command returned.  Why wasn't it?
> 
> Because it wasn't the current-buffer when the command ended.

But that means the whole handling of deactivate-mark is now quite
fragile, isn't it?  A command can change the current buffer any number
of times, touching several buffers, and change back before it returns
to the command loop, and Emacs will be none the wiser.

Here's the proposed patch:

--- lisp/mouse.el~	2016-07-20 09:52:16.559875700 +0300
+++ lisp/mouse.el	2016-07-24 17:14:34.469052800 +0300
@@ -815,14 +815,16 @@ The region will be defined with mark and
   (setq mouse-selection-click-count-buffer (current-buffer))
   (deactivate-mark)
   (let* ((scroll-margin 0) ; Avoid margin scrolling (Bug#9541).
+	 (start-posn (event-start start-event))
+	 (start-point (posn-point start-posn))
+	 (start-window (posn-window start-posn))
+	 (_ (with-selected-window start-window
+	      (setq deactivate-mark nil)))
          ;; We've recorded what we needed from the current buffer and
          ;; window, now let's jump to the place of the event, where things
          ;; are happening.
          (_ (mouse-set-point start-event))
          (echo-keystrokes 0)
-	 (start-posn (event-start start-event))
-	 (start-point (posn-point start-posn))
-	 (start-window (posn-window start-posn))
 	 (bounds (window-edges start-window))
 	 (make-cursor-line-fully-visible nil)
 	 (top (nth 1 bounds))

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.