bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#24030: 25.0.95; mouse-drag-region regression
Date: Sun, 24 Jul 2016 17:12:16 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: agrambot@gmail.com,  24030@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))





reply via email to

[Prev in Thread] Current Thread [Next in Thread]