GNU bug report logs - #6316
24.0.50; unexpected region highlighting with disabled transient-mark-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6316 in the body.
You can then email your comments to 6316 AT debbugs.gnu.org in the normal way.

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50;
	unexpected region highlighting with disabled transient-mark-mode
Date: Mon, 31 May 2010 09:30:34 +0200

1. emacs -Q
2. Type `M-x transient-mark-mode' to disable transient-mark-mode.
3. Select some text with the mouse.  To give a specific example for the
sake of replication, type `C-h v transient-mark-mode RET', then in the
*Help* buffer double click on the left parenthesis of "(only . OLDVAL)"
to select the whole sexp, which thus gets highlighted.
4. Type `M-w', then put point at the start of the paragraph (in *Help*)
beginning "Non-nil also enables highlighting".  Note that the region is
not highlighted.
5. Paste "(only . OLDVAL)" into *scratch*, then double click on "OLDVAL",
selecting and highlighting it.
6. Type `C-x o' to switch back to the *Help* buffer.
=> The region in *Help* between point and the left parenthesis of 
"(only . OLDVAL)" is now highlighted.

This annoying misbehavior has existed for some time, but I can't say
when it first appeared.


In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6)
 of 2010-05-29 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10605000
configured using `configure  '--without-toolkit-scroll-bars''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

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

From: Stephen Berman <Stephen.Berman <at> gmx.net>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50;
	unexpected region highlighting with disabled transient-mark-mode
Date: Mon, 31 May 2010 14:29:16 +0200

On Mon, 31 May 2010 09:30:34 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> 1. emacs -Q
> 2. Type `M-x transient-mark-mode' to disable transient-mark-mode.
> 3. Select some text with the mouse.  To give a specific example for the
> sake of replication, type `C-h v transient-mark-mode RET', then in the
> *Help* buffer double click on the left parenthesis of "(only . OLDVAL)"
> to select the whole sexp, which thus gets highlighted.
> 4. Type `M-w', then put point at the start of the paragraph (in *Help*)
> beginning "Non-nil also enables highlighting".  Note that the region is
> not highlighted.
> 5. Paste "(only . OLDVAL)" into *scratch*, then double click on "OLDVAL",
> selecting and highlighting it.
> 6. Type `C-x o' to switch back to the *Help* buffer.
> => The region in *Help* between point and the left parenthesis of 
> "(only . OLDVAL)" is now highlighted.

I should have mentioned that selection with the mouse is not crucial;
the same unexpected highlighting occurs if selection is done via the
keyboard -- with the important qualification that in step 5, the
selection must be made by typing `C-SPC' twice to activate the mark,
then moving point to the end of "OLDVAL", so that it is highlighted.
(Mark activation is not necessary in step 3, in which case the selected
text would not be highlighted.)

Steve Berman

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Tue, 29 May 2012 22:42:37 +0200

Ping, in case this has been forgotten.  The problem persists in the
current trunk.  I've also truncated the title of the bug report, since
transient-mark-mode is actually irrelevant, as an unrelated posting to
emacs-devel (http://permalink.gmane.org/gmane.emacs.devel/127927>),
excerpted below, shows.  It would be very nice to have this bug fixed.

Steve Berman

On Mon, 31 May 2010 14:29:16 +0200 Stephen Berman <Stephen.Berman <at> gmx.net> wrote:

> On Mon, 31 May 2010 09:30:34 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> 1. emacs -Q
>> 2. Type `M-x transient-mark-mode' to disable transient-mark-mode.
>> 3. Select some text with the mouse.  To give a specific example for the
>> sake of replication, type `C-h v transient-mark-mode RET', then in the
>> *Help* buffer double click on the left parenthesis of "(only . OLDVAL)"
>> to select the whole sexp, which thus gets highlighted.
>> 4. Type `M-w', then put point at the start of the paragraph (in *Help*)
>> beginning "Non-nil also enables highlighting".  Note that the region is
>> not highlighted.
>> 5. Paste "(only . OLDVAL)" into *scratch*, then double click on "OLDVAL",
>> selecting and highlighting it.
>> 6. Type `C-x o' to switch back to the *Help* buffer.
>> => The region in *Help* between point and the left parenthesis of 
>> "(only . OLDVAL)" is now highlighted.
>
> I should have mentioned that selection with the mouse is not crucial;
> the same unexpected highlighting occurs if selection is done via the
> keyboard -- with the important qualification that in step 5, the
> selection must be made by typing `C-SPC' twice to activate the mark,
> then moving point to the end of "OLDVAL", so that it is highlighted.
> (Mark activation is not necessary in step 3, in which case the selected
> text would not be highlighted.)
>
> Steve Berman


On Wed, 28 Jul 2010 00:44:34 +0100 David De La Harpe Golden
<david <at> harpegolden.net> wrote:

[...]
> Note that I can replicate similar issues in emacs 23.2, really:
>
> emacs -Q
> C-x 3
> shift-select "is for notes" in LHS *scratch*. It is highlighted.
> C-x o to RHS *scratch*
>
> Everything from the start of "is for notes" to the end of the buffer is
> highlighted, because that's where the point was in the other window, and
> select-window is "naive" (it just warps to the point saved in the the window).
>
> A fix for select-active-regions somewhat similar to the zero-length regions
> fix proposed approach should certainly be possible - really we don't want to
> propagate the active region of a newly switched-to-window until it "really"
> changes anew post-restoration.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Tue, 27 May 2014 15:57:33 +0200

Could someone who knows how region highlighting works take a look at
this issue, which continues to annoy me?

If I knew how to debug this, I'd try to, but I don't even know how to
start...

Steve Berman

On Tue, 29 May 2012 22:42:37 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> Ping, in case this has been forgotten.  The problem persists in the
> current trunk.  I've also truncated the title of the bug report, since
> transient-mark-mode is actually irrelevant, as an unrelated posting to
> emacs-devel (http://permalink.gmane.org/gmane.emacs.devel/127927>),
> excerpted below, shows.  It would be very nice to have this bug fixed.
>
> Steve Berman
>
> On Mon, 31 May 2010 14:29:16 +0200 Stephen Berman <Stephen.Berman <at> gmx.net> wrote:
>
>> On Mon, 31 May 2010 09:30:34 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>>
>>> 1. emacs -Q
>>> 2. Type `M-x transient-mark-mode' to disable transient-mark-mode.
>>> 3. Select some text with the mouse.  To give a specific example for the
>>> sake of replication, type `C-h v transient-mark-mode RET', then in the
>>> *Help* buffer double click on the left parenthesis of "(only . OLDVAL)"
>>> to select the whole sexp, which thus gets highlighted.
>>> 4. Type `M-w', then put point at the start of the paragraph (in *Help*)
>>> beginning "Non-nil also enables highlighting".  Note that the region is
>>> not highlighted.
>>> 5. Paste "(only . OLDVAL)" into *scratch*, then double click on "OLDVAL",
>>> selecting and highlighting it.
>>> 6. Type `C-x o' to switch back to the *Help* buffer.
>>> => The region in *Help* between point and the left parenthesis of 
>>> "(only . OLDVAL)" is now highlighted.
>>
>> I should have mentioned that selection with the mouse is not crucial;
>> the same unexpected highlighting occurs if selection is done via the
>> keyboard -- with the important qualification that in step 5, the
>> selection must be made by typing `C-SPC' twice to activate the mark,
>> then moving point to the end of "OLDVAL", so that it is highlighted.
>> (Mark activation is not necessary in step 3, in which case the selected
>> text would not be highlighted.)
>>
>> Steve Berman
>
>
> On Wed, 28 Jul 2010 00:44:34 +0100 David De La Harpe Golden
> <david <at> harpegolden.net> wrote:
>
> [...]
>> Note that I can replicate similar issues in emacs 23.2, really:
>>
>> emacs -Q
>> C-x 3
>> shift-select "is for notes" in LHS *scratch*. It is highlighted.
>> C-x o to RHS *scratch*
>>
>> Everything from the start of "is for notes" to the end of the buffer is
>> highlighted, because that's where the point was in the other window, and
>> select-window is "naive" (it just warps to the point saved in the the window).
>>
>> A fix for select-active-regions somewhat similar to the zero-length regions
>> fix proposed approach should certainly be possible - really we don't want to
>> propagate the active region of a newly switched-to-window until it "really"
>> changes anew post-restoration.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Tue, 27 May 2014 11:00:12 -0400

> Could someone who knows how region highlighting works take a look at
> this issue, which continues to annoy me?

I installed a patch which fixes this particular recipe, but this is
a very messy part of transient-mark-mode, so I wouldn't be surprised if
there are other problematic cases.


        Stefan

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Tue, 27 May 2014 22:51:48 +0200

On Tue, 27 May 2014 11:00:12 -0400 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

>> Could someone who knows how region highlighting works take a look at
>> this issue, which continues to annoy me?
>
> I installed a patch which fixes this particular recipe,

I confirm that the unexpected highlighting with the recipe of my OP is
gone, thanks much.

>                                                         but this is
> a very messy part of transient-mark-mode, so I wouldn't be surprised if
> there are other problematic cases.

Indeed, the recipe David De La Harpe Golden gave still produces
unexpected highlighting (though, despite being phenomenologically the
same sort of problem, maybe it's technically different, since it happens
even with transient-mark-mode enabled).

Your patch also does not account for the case of using a motion command
to unhighlight the region when transient-mark-mode is disabled, instead
of using M-w to do that as in my OP.  The reason is apparently that
moving point does not deactivate the mark, unlike M-w or C-g, so your
fix does not come into play.  It's clear that motion commands should not
deactivate the mark when transient-mark-mode is enabled, since they
change the bounds of the active region.  But when transient-mark-mode is
disabled but then temporarily enabled by double clicking or shift
selection, thus highlighting the region, and moving point unhighlights
the region, doesn't it seem reasonable to deactivate the mark in this
case?

Steve Berman

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Mon, 23 Jun 2014 12:31:37 -0400

> Indeed, the recipe David De La Harpe Golden gave still produces
> unexpected highlighting (though, despite being phenomenologically the
> same sort of problem, maybe it's technically different, since it happens
> even with transient-mark-mode enabled).

I installed another patch into trunk which should fix this problem
more thoroughly.  Can you confirm it fixes all the cases you know?


        Stefan

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Tue, 24 Jun 2014 17:59:16 +0200

On Mon, 23 Jun 2014 12:31:37 -0400 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

>> Indeed, the recipe David De La Harpe Golden gave still produces
>> unexpected highlighting (though, despite being phenomenologically the
>> same sort of problem, maybe it's technically different, since it happens
>> even with transient-mark-mode enabled).
>
> I installed another patch into trunk which should fix this problem
> more thoroughly.  Can you confirm it fixes all the cases you know?

It does not fix the above case, though again, since that happens whether
or not transient-mark-mode is enabled, it's probably a different issue.

It does fix the case I mentioned in my previous reply of using a motion
command to unhighlight the region when transient-mark-mode is disabled,
so it improves upon the previous patch in that respect.

However, with your new patch, temporarily enabling transient-mark-mode,
when it is disabled, seems to break transient-mark-mode; here's a
recipe:

0. emacs -Q
1. Sanity check: `M-< C-SPC M-f' results in ";; This" being highlighted.
   Typing `M-x transient-mark-mode' shows the message "Transient-Mark
   mode disabled" and results in ";; This" becoming unhighlighted.
   Now typing `C-SPC M-f M-x transient-mark-mode' shows the message
   "Transient-Mark mode enabled" and results in " buffer" being
   highlighted.
2. Type `M-x transient-mark-mode' to disable transient-mark-mode again.
3. Type `C-SPC C-SPC' to temporarily enable transient-mark-mode, showing
   the message "Mark activated".
4. Type `M-x transient-mark-mode' to enable transient-mark-mode again
   (verified by the message "Transient-Mark mode enabled").
5. Type `C-SPC M-f'
=> The region is not highlighted.  Moreover, `C-h v transient-mark-mode'
   says:
   
   transient-mark-mode is a variable defined in `C source code'.
   Its value is nil
   Original value was t
   Local in buffer *scratch*; global value is t

The same thing happens if in step 3 you use shift-selection instead of
`C-SPC C-SPC'.

Steve Berman

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Tue, 01 Jul 2014 14:14:52 -0400

> However, with your new patch, temporarily enabling transient-mark-mode,
> when it is disabled, seems to break transient-mark-mode; here's a recipe:

Yes, the buffer "remembers" that it was nil.
I installed an additional patch which tries to avoid this problem, tho
it probably comes with other undesirable cases.


        Stefan

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Wed, 02 Jul 2014 11:27:54 +0200

On Tue, 01 Jul 2014 14:14:52 -0400 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

>> However, with your new patch, temporarily enabling transient-mark-mode,
>> when it is disabled, seems to break transient-mark-mode; here's a recipe:
>
> Yes, the buffer "remembers" that it was nil.
> I installed an additional patch which tries to avoid this problem,

I confirm that it fixes that problem.  In addition, it fixes (presumably
in combination with your previous patch) another case of unexpected
region highlighting that differs somewhat from the recipe of my OP:

0. emacs -Q
1. M-x transient-mark-mode (disabling it).
2. C-SPC to set the mark in *scratch*, then move point, creating a
   nonempty region, which, as expected, is not highlighted.
3. Open another buffer, e.g. with `C-h v transient-mark-mode RET' and
   select and highlight a region in it, e.g. with `C-SPC C-SPC M-f'.
4. Switch back to *scratch*.
=> The region in *scratch* is now highlighted.

I observe this in emacs-24, which contains your fix for my OP, but not
in trunk, which also contains your last two patches for this bug report.

> tho it probably comes with other undesirable cases.

I haven't found any new ones yet, and given the above problem, I would
be in favor of backporting your last two patches to emacs-24 (sorry I
didn't notice the above problem earlier).

There is another apparently longer-standing behavior (at least it
happens with -Q in 24.3, as well as emacs-24 and trunk), which I noticed
while testing you latest patch: if you mark and highlight a region in a
buffer and then call e.g. `C-h f' or `C-h v', when the *Help* buffer
opens this unhighlights the region in the other buffer, although the
latter remains the current buffer.  Is this supposed to happen, and if
so, why?  (If it's not supposed to happen, I'll open a new bug.)

Steve Berman

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stephen Berman <stephen.berman <at> gmx.net>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>
Cc: 6316 <at> debbugs.gnu.org
Subject: RE: bug#6316: 24.0.50; unexpected region highlighting
Date: Wed, 2 Jul 2014 06:29:19 -0700 (PDT)

> if you mark and highlight a region in a
> buffer and then call e.g. `C-h f' or `C-h v', when the *Help* buffer
> opens this unhighlights the region in the other buffer, although the
> latter remains the current buffer.  Is this supposed to happen, and if
> so, why?  (If it's not supposed to happen, I'll open a new bug.)

`highlight-nonselected-windows' = t controls whether the region remains
highlighted in nonselected windows.

But after a command the region is deactivated, so depending on your
recipe you will not notice the effect of the variable.  IOW, in your
recipe, your command `C-h v' deactivated the region in the original
buffer.

To see the effect of the variable: C-SPC M-f C-x C-o C-SPC M-f.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 6316 <at> debbugs.gnu.org
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Wed, 02 Jul 2014 15:50:37 +0200

On Wed, 2 Jul 2014 06:29:19 -0700 (PDT) Drew Adams <drew.adams <at> oracle.com> wrote:

>> if you mark and highlight a region in a
>> buffer and then call e.g. `C-h f' or `C-h v', when the *Help* buffer
>> opens this unhighlights the region in the other buffer, although the
>> latter remains the current buffer.  Is this supposed to happen, and if
>> so, why?  (If it's not supposed to happen, I'll open a new bug.)
>
> `highlight-nonselected-windows' = t controls whether the region remains
> highlighted in nonselected windows.

As I noted, when you call `C-h f' or `C-h v', it doesn't make the *Help*
buffer current, i.e., the window containing the now unhighlighted region
is still selected.

> But after a command the region is deactivated, so depending on your
      ^^^^^^^^^^^^^^^
      "After certain non-motion commands, including any command that
changes the text in the buffer," according to (emacs)Mark.

> recipe you will not notice the effect of the variable.  IOW, in your
> recipe, your command `C-h v' deactivated the region in the original
> buffer.

Evidently it did; but should it, and if so, why?

Steve Berman

Message #43 received at 6316-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 6316-done <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#6316: 24.0.50; unexpected region highlighting
Date: Thu, 26 Sep 2019 12:17:48 +0200

[Message part 1 (text/plain, inline)]

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Tue, 01 Jul 2014 14:14:52 -0400 Stefan Monnier <
monnier <at> iro.umontreal.ca> wrote:
>
>>> However, with your new patch, temporarily enabling transient-mark-mode,
>>> when it is disabled, seems to break transient-mark-mode; here's a
recipe:
>>
>> Yes, the buffer "remembers" that it was nil.
>> I installed an additional patch which tries to avoid this problem,
>
> I confirm that it fixes that problem.  In addition, it fixes (presumably
> in combination with your previous patch) another case of unexpected
> region highlighting that differs somewhat from the recipe of my OP:
>
> 0. emacs -Q
> 1. M-x transient-mark-mode (disabling it).
> 2. C-SPC to set the mark in *scratch*, then move point, creating a
>    nonempty region, which, as expected, is not highlighted.
> 3. Open another buffer, e.g. with `C-h v transient-mark-mode RET' and
>    select and highlight a region in it, e.g. with `C-SPC C-SPC M-f'.
> 4. Switch back to *scratch*.
> => The region in *scratch* is now highlighted.
[...]
>> tho it probably comes with other undesirable cases.
>
> I haven't found any new ones yet, and given the above problem, I would
> be in favor of backporting your last two patches to emacs-24 (sorry I
> didn't notice the above problem earlier).

Good.  That confirms that the original issue has been solved.

> There is another apparently longer-standing behavior (at least it
> happens with -Q in 24.3, as well as emacs-24 and trunk), which I noticed
> while testing you latest patch: if you mark and highlight a region in a
> buffer and then call e.g. `C-h f' or `C-h v', when the *Help* buffer
> opens this unhighlights the region in the other buffer, although the
> latter remains the current buffer.  Is this supposed to happen, and if
> so, why?  (If it's not supposed to happen, I'll open a new bug.)

I can't reproduce this on current master.  I'm going to assume that it's
been fixed some time in the last five years.

It therefore looks like everything is done here, and I'm closing this
bug.  If that's incorrect, please reopen the bug.

Best regards,
Stefan Kangas

[Message part 2 (text/html, inline)]

Previous Next

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