GNU bug report logs - #9609
Excessive transient region highlighting with highlight-nonselected-windows

Previous Next

Package: emacs;

Reported by: Glenn Morris <rgm <at> gnu.org>

Date: Tue, 27 Sep 2011 01:44:01 UTC

Severity: normal

Tags: confirmed

Found in versions 24.0.90, 25.1

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Tue, 27 Sep 2011 01:44:01 GMT) Full text and rfc822 format available.

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

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: Excessive transient region highlighting with
	highlight-nonselected-windows
Date: Mon, 26 Sep 2011 21:42:22 -0400
Package: emacs
Version: 24.0.90

emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))' -f make-frame

Two frames open showing the *scratch* buffer, once frame has focus.

With the mouse, click on the "n" of "notes" in the focused frame. Do
not release the mouse. In the other frame, a region starting or ending
at "n" is now selected.

This does not happen in Emacs 23.3. How do I disable this selection of a
region in the non-selected frame?

(Obviously I can set highlight-nonselected-windows nil, but I want that
behaviour for regions I explicitly select.)




bug Marked as found in versions 25.1. Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Thu, 18 Aug 2016 12:37:02 GMT) Full text and rfc822 format available.

Added tag(s) confirmed. Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Thu, 18 Aug 2016 12:37:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Wed, 02 Jun 2021 07:49:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 9609 <at> debbugs.gnu.org
Subject: Re: bug#9609: Excessive transient region highlighting with
 highlight-nonselected-windows
Date: Wed, 02 Jun 2021 09:48:05 +0200
Glenn Morris <rgm <at> gnu.org> writes:

> emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))' -f make-frame
>
> Two frames open showing the *scratch* buffer, once frame has focus.
>
> With the mouse, click on the "n" of "notes" in the focused frame. Do
> not release the mouse. In the other frame, a region starting or ending
> at "n" is now selected.

I can confirm that this is still present in Emacs 28.

Pretty weird behaviour.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Wed, 02 Jun 2021 12:44:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, 9609 <at> debbugs.gnu.org
Subject: Re: bug#9609: Excessive transient region highlighting with
 highlight-nonselected-windows
Date: Wed, 02 Jun 2021 15:43:25 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 02 Jun 2021 09:48:05 +0200
> Cc: 9609 <at> debbugs.gnu.org
> 
> Glenn Morris <rgm <at> gnu.org> writes:
> 
> > emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))' -f make-frame
> >
> > Two frames open showing the *scratch* buffer, once frame has focus.
> >
> > With the mouse, click on the "n" of "notes" in the focused frame. Do
> > not release the mouse. In the other frame, a region starting or ending
> > at "n" is now selected.
> 
> I can confirm that this is still present in Emacs 28.
> 
> Pretty weird behaviour.

Probably we decided that the mouse was dragged because the coordinates
in the other window are different.  Or something like that.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Wed, 02 Jun 2021 13:36:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: rgm <at> gnu.org, 9609 <at> debbugs.gnu.org
Subject: Re: bug#9609: Excessive transient region highlighting with
 highlight-nonselected-windows
Date: Wed, 02 Jun 2021 16:34:52 +0300
> Date: Wed, 02 Jun 2021 15:43:25 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: rgm <at> gnu.org, 9609 <at> debbugs.gnu.org
> 
> > > emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))' -f make-frame
> > >
> > > Two frames open showing the *scratch* buffer, once frame has focus.
> > >
> > > With the mouse, click on the "n" of "notes" in the focused frame. Do
> > > not release the mouse. In the other frame, a region starting or ending
> > > at "n" is now selected.
> > 
> > I can confirm that this is still present in Emacs 28.
> > 
> > Pretty weird behaviour.
> 
> Probably we decided that the mouse was dragged because the coordinates
> in the other window are different.  Or something like that.

Btw, you don't need another frame to demonstrate the issue.  You could
do this instead:

  emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))'
  C-x 2
  Click and hold the mouse button on some character




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Wed, 02 Jun 2021 22:57:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, larsi <at> gnus.org, 9609 <at> debbugs.gnu.org
Subject: Re: bug#9609: Excessive transient region highlighting with
 highlight-nonselected-windows
Date: Thu, 03 Jun 2021 01:02:25 +0300
>> > > emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))' -f make-frame
>> > >
>> > > Two frames open showing the *scratch* buffer, once frame has focus.
>> > >
>> > > With the mouse, click on the "n" of "notes" in the focused frame. Do
>> > > not release the mouse. In the other frame, a region starting or ending
>> > > at "n" is now selected.
>> >
>> > I can confirm that this is still present in Emacs 28.
>> >
>> > Pretty weird behaviour.
>>
>> Probably we decided that the mouse was dragged because the coordinates
>> in the other window are different.  Or something like that.
>
> Btw, you don't need another frame to demonstrate the issue.  You could
> do this instead:
>
>   emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))'
>   C-x 2
>   Click and hold the mouse button on some character

The problem is that currently the mark is not window-local.
I tried such workaround, that fixes the above problem, but it has
other issues.  A proper fix needs to be in some low-level function.

#+begin_src emacs-lisp
;; Make the mark buffer-and-window-local.

(defvar-local mark-active-window nil)

(add-hook 'activate-mark-hook (lambda () (setq mark-active-window (selected-window))))
(advice-add 'activate-mark :after
            (lambda (&rest _args)
              (setq mark-active-window (selected-window)))
            '((name . mark-active-window)))

;; Can't use deactivate-mark-hook because when clicking mouse in another window
;; with the same buffer it calls both activate-mark and deactivate-mark,
;; but deactivate-mark checks if the region is active (region-active-p),
;; and doesn't advance further because mark-active was set to nil in the redisplay
;; hook below.  OTOH, the advice is used unconditionally.
(add-hook 'deactivate-mark-hook (lambda () (setq mark-active-window nil)))
(advice-add 'deactivate-mark :after
            (lambda (&rest _args)
              (setq mark-active-window nil))
            '((name . mark-active-window)))

(defun redisplay--update-mark-active-window (window)
  (when mark-active-window
    (setq mark-active (eq mark-active-window window))))

;; Problem: when compiled without optimization CFLAGS='-O0' then
;; quick region selection experiences lags that results in wrong selection.
;; Another problem is that in ‘follow-mode’ ‘set-mark-command’ messes up windows.
(add-hook 'pre-redisplay-functions #'redisplay--update-mark-active-window)
#+end_src




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Thu, 03 Jun 2021 07:26:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rgm <at> gnu.org, larsi <at> gnus.org, 9609 <at> debbugs.gnu.org
Subject: Re: bug#9609: Excessive transient region highlighting with
 highlight-nonselected-windows
Date: Thu, 03 Jun 2021 10:25:40 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org,  rgm <at> gnu.org,  9609 <at> debbugs.gnu.org
> Date: Thu, 03 Jun 2021 01:02:25 +0300
> 
> >   emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))'
> >   C-x 2
> >   Click and hold the mouse button on some character
> 
> The problem is that currently the mark is not window-local.

But the region's overlay _is_ specific to the window where it is set.
Or are you saying it isn't the region that is highlighted in the other
window?

Btw, we could decide that we don't care about this quirk: it's a
pretty rare and obscure use case.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Thu, 03 Jun 2021 20:34:03 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, larsi <at> gnus.org, 9609 <at> debbugs.gnu.org
Subject: Re: bug#9609: Excessive transient region highlighting with
 highlight-nonselected-windows
Date: Thu, 03 Jun 2021 23:20:48 +0300
>> >   emacs -Q --eval '(progn (setq highlight-nonselected-windows t) (transient-mark-mode -1))'
>> >   C-x 2
>> >   Click and hold the mouse button on some character
>>
>> The problem is that currently the mark is not window-local.
>
> But the region's overlay _is_ specific to the window where it is set.
> Or are you saying it isn't the region that is highlighted in the other
> window?

The region is activated in both windows of the same buffer.
I thought the problem is here.

> Btw, we could decide that we don't care about this quirk: it's a
> pretty rare and obscure use case.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Fri, 04 Jun 2021 09:20:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, larsi <at> gnus.org, 9609 <at> debbugs.gnu.org
Subject: Re: bug#9609: Excessive transient region highlighting with
 highlight-nonselected-windows
Date: Fri, 4 Jun 2021 11:18:55 +0200
>> But the region's overlay _is_ specific to the window where it is set.
>> Or are you saying it isn't the region that is highlighted in the other
>> window?
>
> The region is activated in both windows of the same buffer.
> I thought the problem is here.

What is the region in a non-selected window when point of that window's
buffer and point of that window differ?

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9609; Package emacs. (Fri, 04 Jun 2021 16:41:03 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: rgm <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org,
 9609 <at> debbugs.gnu.org
Subject: Re: bug#9609: Excessive transient region highlighting with
 highlight-nonselected-windows
Date: Fri, 04 Jun 2021 19:35:29 +0300
>>> But the region's overlay _is_ specific to the window where it is set.
>>> Or are you saying it isn't the region that is highlighted in the other
>>> window?
>>
>> The region is activated in both windows of the same buffer.
>> I thought the problem is here.
>
> What is the region in a non-selected window when point of that window's
> buffer and point of that window differ?

After setting the mark in the selected window,
the region is activated in the selected window between the mark and current point,
and also the region is activated in the non-selected window
between the same mark and window-point of the non-selected window.




This bug report was last modified 4 years and 8 days ago.

Previous Next


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