all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 24030@debbugs.gnu.org, agrambot@gmail.com
Subject: bug#24030: 25.0.95; mouse-drag-region regression
Date: Sun, 24 Jul 2016 17:12:16 +0300	[thread overview]
Message-ID: <83zip7t9a7.fsf@gnu.org> (raw)
In-Reply-To: <jwvlh0sys12.fsf-monnier+Inbox@gnu.org> (message from Stefan Monnier on Sat, 23 Jul 2016 17:16:37 -0400)

> 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	other threads:[~2016-07-24 14:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 22:11 bug#24030: 25.0.95; mouse-drag-region regression Alex
2016-07-20 14:40 ` Eli Zaretskii
2016-07-22  6:09   ` Alex
2016-07-23 13:02     ` Eli Zaretskii
2016-07-23 17:17       ` Stefan Monnier
2016-07-23 17:56         ` Eli Zaretskii
2016-07-23 21:16           ` Stefan Monnier
2016-07-24 14:12             ` Eli Zaretskii [this message]
2016-07-24 15:02               ` Stefan Monnier
2016-07-24 15:17                 ` Eli Zaretskii
2016-07-24 20:16                   ` Stefan Monnier
2016-07-30  8:33                     ` Eli Zaretskii
2016-07-24 17:33               ` Alex

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zip7t9a7.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=24030@debbugs.gnu.org \
    --cc=agrambot@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.