GNU bug report logs - #15960
24.3.50; Provide a good way to tell when in `mouse-drag-track' (regression)

Previous Next

To reply to this bug, email your comments to 15960 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Provide a good way to tell when in `mouse-drag-track'
 (regression)
Date: Sat, 23 Nov 2013 11:39:43 -0800 (PST)

I have code (library modeline-posn.el) that lets users optionally show
the active region size (highlighted) in the minibuffer, in place of the
buffer size.

My code did this, to test whether the region was active or the user
wants to allow an empty region to be highlighted:

(and transient-mark-mode  mark-active
       (or modelinepos-empty-region-flag
           (/= (region-beginning) (region-end))))

With `modelinepos-empty-region-flag' non-nil, this made it easy for a
user to see when the active region is empty.  (The mode-line size
indication is highlighted with face `region'.)

Emacs 24 changed things, so that this mode-line highlighting now
appeared immediately when you press `mouse-1', and did not wait until
you actually drag the mouse or release `mouse-1'.

This broke the user experience for this feature, because now each time
s?he clicked `mouse-1', without any dragging, a zero-size-region
indication showed in the mode line for as long as `mouse-1' was held
down during the click.  IOW, an annoying flash.

Obviously that is no good, so I updated my code to try to test whether
we are inside `mouse-drag-track'.  I found no clean and sure way to do
this, so I currently test `echo-keystrokes', which `mouse-drag-track'
binds to 0.  This seems to work fine, but it is obviously indirect and
fragile.

The bug report is to request some clearer, cleaner, and surer way to
tell whether we are in `mouse-drag-track'.

This is the code I use now for the test:

(defun modelinepos-empty-region-p ()
  "Return non-nil if region is active and empty.
But do not return non-nil if this is true but you are selecting with
the mouse.  This is to prevent highlighting in the mode line whenever
you press `mouse-1' without dragging at least one character."

  ;; Fragile hack: Starting with Emacs 24, the region is considered
  ;; empty as soon as you press `mouse-1' (`down-mouse-1').  That causes
  ;; modeline highlighting each time you just click `mouse-1', i.e.,
  ;; without dragging it.
  ;;
  ;; The hack is to check whether `echo-keystrokes' is 0.
  ;; `mouse-drag-track' binds `echo-keystrokes' to 0, and that seems to
  ;; be the only way to tell whether we are in `mouse-drag-track'.
  ;; If the Emacs code for that changes then this might break.
  (and transient-mark-mode  mark-active
       (or (if (> emacs-major-version 23)
               (and (not (eq 0 echo-keystrokes))
                    modelinepos-empty-region-flag)
             modelinepos-empty-region-flag)
           (/= (region-beginning) (region-end)))))


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-11-12 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15960 <at> debbugs.gnu.org
Subject: Re: bug#15960: 24.3.50;
 Provide a good way to tell when in `mouse-drag-track' (regression)
Date: Sat, 23 Nov 2013 17:04:29 -0500

> Emacs 24 changed things, so that this mode-line highlighting now
> appeared immediately when you press `mouse-1', and did not wait until
> you actually drag the mouse or release `mouse-1'.

Might simply be a bug.  I suggest you focus on tracking why this is.


        Stefan

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15960 <at> debbugs.gnu.org
Subject: RE: bug#15960: 24.3.50; Provide a good way to tell when in
 `mouse-drag-track' (regression)
Date: Sat, 23 Nov 2013 15:21:35 -0800 (PST)

> > Emacs 24 changed things, so that this mode-line highlighting now
> > appeared immediately when you press `mouse-1', and did not wait
> > until you actually drag the mouse or release `mouse-1'.
> 
> Might simply be a bug.  I suggest you focus on tracking why this is.

It might.  I have no objection to it being seen as a bug, and fixed.

But the behavior of the highlighting appearing now before you release
mouse-1 is a definite improvement.  I would not wish to see that lost
because of the "fix".  This just should not happen unless at least one
char is selected.

In any case, Chong Yidong (I think) changed the code considerably for
Emacs 24.  It will take someone more knowledgable than I to figure it
out, let alone figure out just what was intended vs what might have
been accidental.

Providing a good, clean way to tell whether `mouse-drag-track' is in
progress (e.g. `mouse-tracking-p') would solve the problem I am
reporting.  I would guess that it might also be useful more generally.

But if you don't see it that way and don't want to fix this, I'll
continue to rely on (eq 0 echo-keystrokes) as the test for this.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15960 <at> debbugs.gnu.org
Subject: Re: bug#15960: 24.3.50;
 Provide a good way to tell when in `mouse-drag-track' (regression)
Date: Sat, 23 Nov 2013 19:42:50 -0500

> But the behavior of the highlighting appearing now before you release
> mouse-1 is a definite improvement.  I would not wish to see that lost
> because of the "fix".  This just should not happen unless at least one
> char is selected.

Sounds right.  That's why I think it's just a bug/misfeature.

> Providing a good, clean way to tell whether `mouse-drag-track' is in
> progress (e.g. `mouse-tracking-p') would solve the problem I am
> reporting.

It would just give you a way to work around the problem.  I'd much
rather fix it instead.


        Stefan

Previous Next

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