unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Yuri Khan <yurivkhan@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
Subject: Re: Mark set by ‘mark-*’ not deactivated by point motion
Date: Tue, 18 Sep 2018 13:24:17 +0700	[thread overview]
Message-ID: <CAP_d_8WpmtkLtm=V+K51nMN9cn7MTH6vmgFjHHqCF4iCa3S+jQ@mail.gmail.com> (raw)
In-Reply-To: <jwvy3c00wxx.fsf-monnier+gmane.emacs.help@gnu.org>

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.



  parent reply	other threads:[~2018-09-18  6:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 17:25 Mark set by ‘mark-*’ not deactivated by point motion Yuri Khan
2018-09-17 18:25 ` Eli Zaretskii
2018-09-17 19:18 ` Stefan Monnier
2018-09-17 19:39   ` Mark set by ?mark-*? " Drew Adams
2018-09-18  6:24   ` Yuri Khan [this message]
     [not found]   ` <mailman.897.1537213211.1284.help-gnu-emacs@gnu.org>
2018-09-18  8:45     ` Loris Bennett
2018-09-18 11:45       ` Eli Zaretskii
     [not found]       ` <mailman.918.1537271124.1284.help-gnu-emacs@gnu.org>
2018-09-19  6:33         ` Loris Bennett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP_d_8WpmtkLtm=V+K51nMN9cn7MTH6vmgFjHHqCF4iCa3S+jQ@mail.gmail.com' \
    --to=yurivkhan@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).