Mark set by ‘mark-*’ not deactivated by point motion

Mark set by ‘mark-*’ not deactivated by point motion

[Yuri Khan]

Hello,

the raging discussion about the region models in emacs-devel reminded
me of an annoyance that I never took the time to report.

$ emacs -Q
M-x emacs-version
→ GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
of 2018-05-29
M-: transient-mark-mode
→ t
M-: shift-select-mode
→ t

1. Move point before the word “buffer” in the first line in *scratch*.
2. Press M-@ for ‘mark-word’. Observe that the mark is set after the
word ”buffer” and activated.
3. Move point with an unshifted point motion key.

Observed behavior: point moves as commanded, mark remains active.

Expected behavior: point moves, mark is deactivated.

Carefully looking at the docstring of shift-select-mode and the
implementation code in simple.el, I see that unshifted point motion
keys only deactivate mark if it was activated by shift-selection, but
it runs against my general expectation that selection goes away after
any motion that is not specifically directed to extend/shrink
selection. The only exception I’d make is C-SPC ‘set-mark-command’
because I see that as an explicit command to start marking an active
region without holding down Shift (e.g. as a workaround for terminals
that do not report Shift+arrows to the application).

Pre-emptive counterarguments:

“You could use Ctrl+Shift+<right> to mark a word in a way that will be
deactivate on motion.” — Yes, but the issue also affects mark-sexp,
mark-end-of-sentence, mark-paragraph, mark-defun, and mark-page, and
not all of these have shift-translatable motion equivalent. (E.g.
forward-paragraph is on M-} which is already shifted, and forward-page
is on C-x ] whose shifted version, C-x }, is bound to
enlarge-window-horizontally.)

“You could advise mark-* so that they set transient-mark-mode the same
way as shift-selection does.” — Why yes, I could. Thanks.

(defun yk-mark-*:after (&rest _args)
  (setq-local transient-mark-mode (cons 'only transient-mark-mode)))

(advice-add 'mark-word :after 'yk-mark-*:after)
(advice-add 'mark-sexp :after 'yk-mark-*:after)
…
(advice-add 'mark-whole-buffer :after 'yk-mark-*:after)

Re: Mark set by ‘mark-*’ not deactivated by point motion

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Tue, 18 Sep 2018 00:25:31 +0700
> 
> 1. Move point before the word “buffer” in the first line in *scratch*.
> 2. Press M-@ for ‘mark-word’. Observe that the mark is set after the
> word ”buffer” and activated.
> 3. Move point with an unshifted point motion key.
> 
> Observed behavior: point moves as commanded, mark remains active.
> 
> Expected behavior: point moves, mark is deactivated.

Not sure why you expected the mark to deactivate in this scenario.
How is this different from typing "C-x C-x" instead of M-@ (with the
rest of the recipe the same)?

> it runs against my general expectation that selection goes away after
> any motion that is not specifically directed to extend/shrink
> selection.

Selection does, but you didn't create any selections by the above
sequence of actions.  You've set a region and activated it.
Shift-selection is not the same.

Re: Mark set by ‘mark-*’ not deactivated by point motion

[Stefan Monnier]

> Observed behavior: point moves as commanded, mark remains active.
> Expected behavior: point moves, mark is deactivated.

Could you clarify what would be the benefit of the behavior you expect
(other than fitting your expectation, obviously ;-)?

> Pre-emptive counterarguments:

I'm more wondering about why you'd mark a word with M-@ only to
immediately afterwards deactivate the region.

I never use M-@ but I use C-M-SPC all the time, and very often I do
C-M-SPC (maybe repeated a few times) followed by some cursor motion
(including C-x C-x sometimes) to "fine tune" the boundaries of the
active region.

So I rely on this behavior very frequently and I find it rather
convenient not to have to re-activate the mark explicitly when I'm done
tuning its boundaries.

On the contrary, I find the deactivate-mark behavior of
"navigation after shifted-navigation" to be a mis-feature: it forces me
to be careful to keep the shift key pressed until I'm really done
setting up the region and it prevents me from using navigation commands
which I can't use in a shifted form (or which don't (yet) support
shift-select-mode).  I don't mind very much, tho: I just use C-SPC
instead, but I think in terms of UI, navigation should never deactivate
the mark.

I have the impression that this behavior was simply copied from other
applications, and those don't have something equivalent to Emacs's C-g,
so their users are used to making a dummy un-shifted cursor movement
when they just want to deactivate the selection.  But in Emacs we have
C-g for that.


        Stefan


[ Side comment.  Emacs made the opposite choice for undo: when you want
  to start redoing, you need to perform some dummy non-undo command
  because there's no dedicated key-binding to switch between undo
  and redo.  ]

RE: Mark set by ?mark-*? not deactivated by point motion

[Drew Adams]

> I'm more wondering about why you'd mark a word with M-@ only to
> immediately afterwards deactivate the region.
> 
> I never use M-@ but I use C-M-SPC all the time, and very often I do
> C-M-SPC (maybe repeated a few times) followed by some cursor motion
> (including C-x C-x sometimes) to "fine tune" the boundaries of the
> active region.
> 
> So I rely on this behavior very frequently and I find it rather
> convenient not to have to re-activate the mark explicitly when I'm done
> tuning its boundaries.
> 
> On the contrary, I find the deactivate-mark behavior of
> "navigation after shifted-navigation" to be a mis-feature: it forces me
> to be careful to keep the shift key pressed until I'm really done
> setting up the region and it prevents me from using navigation commands
> which I can't use in a shifted form (or which don't (yet) support
> shift-select-mode).  I don't mind very much, tho: I just use C-SPC
> instead, but I think in terms of UI, navigation should never deactivate
> the mark.
> 
> I have the impression that this behavior was simply copied from other
> applications, and those don't have something equivalent to Emacs's C-g,
> so their users are used to making a dummy un-shifted cursor movement
> when they just want to deactivate the selection.  But in Emacs we have
> C-g for that.

I can see both points of view. The behavior objected to here by
Yuri is fairly standard in Emacs, but Emacs does not follow it
everywhere.

A case where the behavior follows instead what Yuri expects for
this is selecting text with the mouse (in any way: double-click,
mouse-1 then mouse-3 etc.). In this case immediately subsequent
cursor motion does deactivate the region.

Whether Emacs should be consistent in this regard, I don't know.
But apparently Emacs presumes that if you use `M-@' to select a
word (put the active region around it) then you intend cursor
motion to extend it. And apparently it presumes that if you
double-click  mouse-1 to select it then you do not intend cursor
motion to extend it.

A guess is that the latter choice is because it presumes that you
will use only the mouse to extend it. That's not bad reasoning,
I think, but it does make for some inconsistency, so maybe it
can confuse some users.

I tend to like the existing behavior, FWIW. But especially in
cases where there is no mouse equivalent I think it's helpful
to be able to use keyboard and mouse together indifferently.
In that context, see bug #32747.

Re: Mark set by ‘mark-*’ not deactivated by point motion

[Yuri Khan]

On Tue, Sep 18, 2018 at 2:23 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > Observed behavior: point moves as commanded, mark remains active.
> > Expected behavior: point moves, mark is deactivated.
>
> Could you clarify what would be the benefit of the behavior you expect
> (other than fitting your expectation, obviously ;-)?

The benefit is not obvious at first, but I think it is a matter of UI
modality. See below.

> I'm more wondering about why you'd mark a word with M-@ only to
> immediately afterwards deactivate the region.
>
> I never use M-@ but I use C-M-SPC all the time, and very often I do
> C-M-SPC (maybe repeated a few times) followed by some cursor motion
> (including C-x C-x sometimes) to "fine tune" the boundaries of the
> active region.

I actually noticed this behavior from C-M-SPC ‘mark-sexp’ and M-h in
org-mode ‘org-mark-element’. I never use mark-word either, because
C-S-arrows do the same thing and work in all applications.

My scenario is: I press the key to mark something, but I started in
the wrong place so it marked the wrong thing, so I want to move to the
correct place and press it again.

To fine-tune, I would probably use Shift+arrows, possibly combined
with C-x C-x. But I don’t really do that; it’s easier to start over.

> On the contrary, I find the deactivate-mark behavior of
> "navigation after shifted-navigation" to be a mis-feature: it forces me
> to be careful to keep the shift key pressed until I'm really done
> setting up the region and it prevents me from using navigation commands
> which I can't use in a shifted form (or which don't (yet) support
> shift-select-mode).  I don't mind very much, tho: I just use C-SPC
> instead, but I think in terms of UI, navigation should never deactivate
> the mark.
>
> I have the impression that this behavior was simply copied from other
> applications, and those don't have something equivalent to Emacs's C-g,
> so their users are used to making a dummy un-shifted cursor movement
> when they just want to deactivate the selection.  But in Emacs we have
> C-g for that.

You are used to modal selection. You press C-SPC and now all
navigation commands mark a region. Then you press C-g or perform a
region command to return to normal mode.

I am used to quasi-modal selection. Navigation commands mark a region
only as long as I hold down the pedal, and the region is active only
as long as I haven’t moved away from it. This is important when
delete-selection-mode is on, because a stray region can easily be
deleted or replaced.

Dummy <end> or <left><right> keypresses (in other applications) are a
thing, yes. But most of the time the need to deactivate selection is
tied with the need to move to a different place.

> [ Side comment.  Emacs made the opposite choice for undo: when you want
>   to start redoing, you need to perform some dummy non-undo command
>   because there's no dedicated key-binding to switch between undo
>   and redo.  ]

Yes, and that design choice leads to the same consequence of modality:
C-_ behaves differently depending on what you did before. I use
redo.el to have separate bindings, C-z for undo, C-S-z for redo.

Re: Mark set by ?mark-*? not deactivated by point motion

[Loris Bennett]

Drew Adams <drew.adams@oracle.com> writes:

[snip (36 lines)]

> Whether Emacs should be consistent in this regard, I don't know.
> But apparently Emacs presumes that if you use `M-@' to select a
> word (put the active region around it) then you intend cursor
> motion to extend it. And apparently it presumes that if you
> double-click  mouse-1 to select it then you do not intend cursor
> motion to extend it.

With my Emacs 25.1.1 `M-@' select the part of the word from the cursor
to the end of the word.  Moving the cursor left extends the region,
whereas moving it right unselects when over the initially selected
section and extends beyond that.

So if I have

  able baker charlie

and do `M-@' while on 'k',

         ker

is selected.  If I move left to 'a', then

  able baker

is selected.  If instead I move right to the final 'e', then

             charlie

including the space in front of the 'c' is selected.

Is that supposed to happen?  What's the use-case for the moving-right
behaviour?

[snip (11 lines)]

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Mark set by ?mark-*? not deactivated by point motion

[Eli Zaretskii]

> From: "Loris Bennett" <loris.bennett@fu-berlin.de>
> Date: Tue, 18 Sep 2018 10:45:50 +0200
> 
> So if I have
> 
>   able baker charlie
> 
> and do `M-@' while on 'k',
> 
>          ker
> 
> is selected.  If I move left to 'a', then
> 
>   able baker
> 
> is selected.  If instead I move right to the final 'e', then
> 
>              charlie
> 
> including the space in front of the 'c' is selected.
> 
> Is that supposed to happen?

Yes.

> What's the use-case for the moving-right behaviour?

To allow you to adjust the beginning of the region.

Re: Mark set by ?mark-*? not deactivated by point motion

[Loris Bennett]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Loris Bennett" <loris.bennett@fu-berlin.de>
>> Date: Tue, 18 Sep 2018 10:45:50 +0200
>> 
>> So if I have
>> 
>>   able baker charlie
>> 
>> and do `M-@' while on 'k',
>> 
>>          ker
>> 
>> is selected.  If I move left to 'a', then
>> 
>>   able baker
>> 
>> is selected.  If instead I move right to the final 'e', then
>> 
>>              charlie
>> 
>> including the space in front of the 'c' is selected.
>> 
>> Is that supposed to happen?
>
> Yes.
>
>> What's the use-case for the moving-right behaviour?
>
> To allow you to adjust the beginning of the region.

Sorry, I was getting confused by the name 'mark-word'.  I naively
assumed the main purpose would be to mark the word at point and then
extend the selection if desired.  Reading the description of the
function I see it more to do with selecting a region by the number of
words in it.

Cheers,

Loris

-- 
This signature is currently under construction.