GNU bug report logs - #19513
shift-select-mode fails to be fully buffer-local

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 19513 in the body.
You can then email your comments to 19513 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: Kelly Dean <kelly <at> prtime.org>
To: bug-gnu-emacs <at> gnu.org
Subject: shift-select-mode fails to be fully buffer-local
Date: Mon, 05 Jan 2015 01:06:04 +0000

With Emacs 24.4, do emacs -Q, get two windows in your frame, and different buffers in the windows, and some text in each buffer.
In one of them, (setq-local shift-select-mode nil).
In each of them, try shifted motion followed by non-shifted motion, and you get the expected result. That indicates that shift-select-mode is buffer-local.
You trigger the bug like this:
Switch to the window with the buffer with shift-select-mode on. Do shifted motion, but not non-shifted, so the selection remains.
C-x o
Do any motion (shifted or non-shifted), and you get the expected result (no selection).
C-x o
Do non-shifted motion, which is supposed to turn off the selection. However, the selection remains.

I know you'll consider it weird to want to buffer-locally disable shift-select-mode. But the mode is enabled and disabled by setting a variable, Emacs supports buffer-local variables (which aren't supposed to affect other buffers), and I don't see anything in the docs that says the shift-select-mode variable is an exception to buffer-locality. So the above behavior is a bug.

The reason I want to do that is I have a minor mode that depends on shift-select-mode being disabled. I never use shift-select-mode myself, so I always have it disabled, but I'm trying to enhance my mode so it will work for everybody else. I could simply disable shift-select-mode globally while my mode is enabled (and restore the former setting when my mode is disabled), but that would affect all buffers, not just the buffer in which my mode is enabled. The right way to do it is to buffer-locally disable shift-select-mode, but the bug above prevents that.

The easy solution is to remove shift-select-mode from Emacs. That's what I vote for, but I guess I'm in the minority. ;-)

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Kelly Dean <kelly <at> prtime.org>
Cc: 19513 <at> debbugs.gnu.org
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Sun, 04 Jan 2015 21:09:27 -0500

> I know you'll consider it weird to want to buffer-locally disable
> shift-select-mode.

Indeed.  I actually find it weird to want to disable shift-select-mode
globally as well.

Could you explain why you want to disable-it buffer-locally?

> So the above behavior is a bug.

Agreed.  It's got pretty low priority for me, tho.

> The reason I want to do that is I have a minor mode that depends on
> shift-select-mode being disabled.

Can you explain how/why?

> I never use shift-select-mode myself,

Neither do I, but I've always kept it enabled since it appeared, and
I never bumped into it, so it seems pretty harmless in "normal" use.

> The easy solution is to remove shift-select-mode from Emacs.  That's what
> I vote for, but I guess I'm in the minority. ;-)

Yes, I think you're in a very small minority here.  I think it'll be
much easier to make your minor mode work with shift-select-mode.


        Stefan

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

From: Kelly Dean <kelly <at> prtime.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19513 <at> debbugs.gnu.org
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Tue, 06 Jan 2015 06:59:39 +0000

Stefan Monnier wrote:
>> The reason I want to do that is I have a minor mode that depends on
>> shift-select-mode being disabled.
>
> Can you explain how/why?

See line-select-minor-mode in the section beginning on line 339 at
http://prtime.org/emacs/vimizer.el (currently version 0.2.2)

Comment out lines 384-385 to enable it to work with shift-select-mode, to see how the latter interferes.
Enable the mode, then press S-down. Then press down, and since you're doing a non-shifted motion command following a shifted motion command, shift-select-mode deactivates the region.

The region is supposed to stay active while line-select mode is on, and line-select is supposed to remain on until you actually do something that's supposed to deactivate the region, e.g. C-g, C-w, etc. Motion commands specifically are _not_ supposed to deactivate it, which is why I need shift-select-mode disabled while the line-select mode is on.

The reason it's a problem for motion commands to deactivate it is that I have a lot of keys bound to different motion commands depending on whether shift is pressed. E.g. I have a key bound to right-word, and the same key shifted is bound to forward-sexp. So I frequently press a combination of both shifted and non-shifted keys to move, including even when line-select is on. Normally, shift-select-mode doesn't deactivate the region, since it ignores my rebound keys, but when I happen to press a shifted key that I _don't_ have rebound (e.g. S-left, which Emacs translates to left, bound to the default of left-char), shift-select-mode notices it, and then deactivates the region upon the following non-shifted motion command.

You could say, just avoid pressing S-left, but that's not user-friendly. If I'm doing a sequence of motion commands that happen to be bound to shifted keys, and I need to do left-char in the middle of the sequence, I shouldn't have to un-press shift just to prevent shift-select-mode from biting me the next time I use a non-shifted key.

> Could you explain why you want to disable-it buffer-locally?

So that if line-select is active (which requires shift-select inactive) in one buffer, it doesn't interfere with the user's ability to use shift-select in another buffer.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Kelly Dean <kelly <at> prtime.org>
Cc: 19513 <at> debbugs.gnu.org
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Tue, 06 Jan 2015 10:24:01 -0500

> Comment out lines 384-385 to enable it to work with shift-select-mode, to see how the latter interferes.
> Enable the mode, then press S-down.  Then press down, and since you're
> doing a non-shifted motion command following a shifted motion command,
> shift-select-mode deactivates the region.

I'm not sure it should be considered as a bug, or at least one specific
to line-select-minor-mode.

The same behavior shows up if you do (in "emacs -Q"):

  C-SPC next S-next

and you see that the S-next ended the previous selection and started
a new one.  Some might see it as a feature (I don't know if it was
implemented this way on purpose or by accident).

If we see it as a bug the right answer is probably to change
shift-select-mode such that shifted-motion doesn't start a new
shift-selection if we're already in the middle of an
"old-style" selection.

Since you have shift-select-mode disabled globally, you shouldn't
care anyway, so I guess you're doing this in response to complaints from
users of vimizer.  If so, do they usually use shift-select-mode?
If not, maybe the right answer is to tell them they should disable
shift-select-mode.


        Stefan

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

From: Kelly Dean <kelly <at> prtime.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 19513 <at> debbugs.gnu.org
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Tue, 06 Jan 2015 19:20:11 +0000

Stefan Monnier wrote:
> The same behavior shows up if you do (in "emacs -Q"):
>
>   C-SPC next S-next
>
> and you see that the S-next ended the previous selection and started
> a new one.  Some might see it as a feature (I don't know if it was
> implemented this way on purpose or by accident).
>
> If we see it as a bug the right answer is probably to change
> shift-select-mode such that shifted-motion doesn't start a new
> shift-selection if we're already in the middle of an
> "old-style" selection.

If that's a bug, then it's a different one; it isn't the behavior that #19513 is about. But if it is a bug, and gets fixed, then it appears shift-select would no longer interfere with line-select (which uses ‟old-style” selection), so I'd have no need to buffer-locally disable shift-select, which means I wouldn't care if #19513 is never fixed.

> Since you have shift-select-mode disabled globally, you shouldn't
> care anyway, so I guess you're doing this in response to complaints from
> users of vimizer.  If so, do they usually use shift-select-mode?

I'm the only user of vimizer. I haven't sent it to a package repository yet, because I only recently had time to disentangle it from the rest of my custom code and make a standalone package, and I need to dogfood it for a while to make sure I didn't introduce any new bugs. When I do send it, other people won't want to have to globally disable shift-select.

> If not, maybe the right answer is to tell them they should disable
> shift-select-mode.

Right now, line-select does say it's incompatible with shift-select, and refuses to turn on unless shift-select is disabled. But that's a poor workaround.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Kelly Dean <kelly <at> prtime.org>
Cc: 19513 <at> debbugs.gnu.org
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Tue, 06 Jan 2015 16:06:02 -0500

> I'm the only user of vimizer. I haven't sent it to a package repository yet,
> because I only recently had time to disentangle it from the rest of my
> custom code and make a standalone package, and I need to dogfood it
> for a while to make sure I didn't introduce any new bugs. When I do send it,
> other people won't want to have to globally disable shift-select.

It definitely shouldn't globally disable shift-select-mode.  But the
behavior you seem not to like doesn't look like a bug to me (the
bug#19513 is indeed a bug, OTOH), and I don't see any obvious reason why
it should look like a bug to other users.

>> If not, maybe the right answer is to tell them they should disable
>> shift-select-mode.
> Right now, line-select does say it's incompatible with shift-select, and
> refuses to turn on unless shift-select is disabled. But
> that's a poor workaround.

I don't think it's incompatible.  Maybe you don't like the interaction,
but I think it's just because you don't like shift-select-mode's current
behavior.


        Stefan

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

From: Kelly Dean <kelly <at> prtime.org>
To: 19513 <at> debbugs.gnu.org
Subject: Re: shift-select-mode fails to be fully buffer-local
Date: Sun, 25 Jan 2015 08:50:35 +0000

The bug was caused because handle-shift-selection sets transient-mark-mode globally to a cons with 'only as the car, then when the motion command occurs in the other buffer, handle-shift-selection sets transient-mark-mode globally to remove that cons, so back in the first buffer, when handle-shift-selection is called again, the cons is gone, so there's no trigger to deactivate the mark.

Setting transient-mark-mode buffer-locally instead of globally fixes the bug.

I was about to send a patch, but when I checked to make sure it applied to trunk, I discovered Stefan already fixed this bug in commit 5d2638bd in June 2014--more than three months before 24.4 was released.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Kelly Dean <kelly <at> prtime.org>
Cc: 19513 <at> debbugs.gnu.org
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Sun, 25 Jan 2015 10:16:47 -0500

> I was about to send a patch, but when I checked to make sure it applied to
> trunk, I discovered Stefan already fixed this bug in commit 5d2638bd in June
> 2014--more than three months before 24.4 was released.

We could backport this patch to `emacs-24'.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kelly Dean <kelly <at> prtime.org>
Cc: 19513 <at> debbugs.gnu.org
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Sun, 25 Jan 2015 17:40:01 +0200

> From: Kelly Dean <kelly <at> prtime.org>
> Date: Sun, 25 Jan 2015 08:50:35 +0000
> 
> I was about to send a patch, but when I checked to make sure it applied to trunk, I discovered Stefan already fixed this bug in commit 5d2638bd in June 2014--more than three months before 24.4 was released.

But it was fixed on the trunk, not on the emacs-24 branch from which
Emacs 24.4 was released.  So the fact that it was before the release
doesn't matter.

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

From: Kelly Dean <kelly <at> prtime.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 19513 <at> debbugs.gnu.org
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Mon, 26 Jan 2015 04:16:09 +0000

Stefan Monnier wrote:
> We could backport this patch to `emacs-24'.

Wouldn't that only matter if there's going to be another 24 release? I thought 25.1 was next, since ⌜25.0.50⌝ is appearing in everybody's User-Agent headers.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kelly Dean <kelly <at> prtime.org>
Cc: 19513 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#19513: shift-select-mode fails to be fully buffer-local
Date: Mon, 26 Jan 2015 08:15:27 +0200

> From: Kelly Dean <kelly <at> prtime.org>
> Date: Mon, 26 Jan 2015 04:16:09 +0000
> Cc: 19513 <at> debbugs.gnu.org
> 
> Stefan Monnier wrote:
> > We could backport this patch to `emacs-24'.
> 
> Wouldn't that only matter if there's going to be another 24 release?

Yes, and there's going to be one, hopefully very soon.  Too many bugs
in 24.4 were fixed since its release, so a bugfix release is in order.

Previous Next

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