bug#19513: shift-select-mode fails to be fully buffer-local

[Kelly Dean <kelly@prtime.org>]

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.