unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Dani Moncayo'" <dmoncayo@gmail.com>
Cc: 10056@debbugs.gnu.org
Subject: bug#10056: 24.0.91; Mark deactivation
Date: Fri, 25 Jan 2013 11:34:18 -0800	[thread overview]
Message-ID: <61EA87D1494E46E9AA03ACEDF88E7CD4@us.oracle.com> (raw)
In-Reply-To: <CAH8Pv0hc78QPL3XahPNXKZuMskxSj-3jJVmE_PQHm8KLvVntqQ@mail.gmail.com>

> Well, the reason is the same for all commands I've mentioned: In my
> experience (or my usage pattern), after defining an active region and
> invoking a command to operate on it, it's much more likely that the
> next commands have nothing to do with that active region.  IOW, I
> almost always set up an active region to do a single operation on it,
> not several ones.  So keeping the region active is, at best, counter
> intuitive and visually annoying to me.

I agree, and I think that's the general rule, i.e., the behavior by default.  I
think the command loop automatically does that, unless a given command
explicitly inhibits it.

And I have no objection to that general default behavior.  I would object,
though, if we were to somehow stop an individual command from inhibiting
deactivation.

Wrt `eval-region', I have no objection to deactivation.  But I wonder why that
does not happen automatically.

I don't have the C code available, but presumably it explicitly inhibits
deactivation (?).  If so, I wonder what the designers had in mind, IOW, why that
inhibition in this case?  Maybe you can do some archaeology to find out the
history?

> > Wrt your footnote [2]: Why should we deactivate the region 
> > for _any_ command when it is called non-interactively?
> > That doesn't make sense to me (yet - but I'm willing to learn why).
> 
> That footnote is about `narrow-to-region', not about "any command".

Yes, I understood that it is about `narrow-to-region'.  I wondered why Yidong
would bother to say that specifically about `narrow-to-region', since it should
be true of _all_ commands, AFAIK.

Unless a particular command is somehow a special case (are there any such?), we
should not automatically deactivate the region for _any_ command when it is
called non-interactively.

If Lisp code that calls a command wants to deactivate the mark it can do that.
_Automatic_ deactivation should be only for interactive invocation, IMO.

> But, well, I'm thinking that perhaps the mark deactivation I'm
> requesting should be specific to interactive calls.

Yes.  And I think that is the case wrt automatic deactivation.

> After all, what I want to avoid is just the annoyance of having
> to type `C-g' to deactivate the mark after realizing that Emacs
> didn't do it for me.

Yes, and that too should already be the case in general: automatic deactivation
for any command that does not, itself, explicitly inhibit deactivation.






  reply	other threads:[~2013-01-25 19:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15 20:06 bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Dani Moncayo
2011-11-15 20:15 ` Dani Moncayo
2011-11-15 20:36   ` Dani Moncayo
2011-11-15 20:18 ` Dani Moncayo
2011-11-21  6:30 ` Chong Yidong
2012-06-05  7:44   ` Dani Moncayo
2012-07-28 19:01   ` Dani Moncayo
2012-07-29  4:45     ` Chong Yidong
2012-07-29  9:46       ` Dani Moncayo
2012-07-29  4:50     ` Chong Yidong
2012-07-29 10:01       ` Dani Moncayo
2012-08-01 21:17         ` Alan Mackenzie
2012-08-01 22:07           ` Dani Moncayo
2012-08-03 21:47             ` Alan Mackenzie
2012-09-08 20:21           ` Stefan Monnier
2012-09-09 20:20             ` Dani Moncayo
2012-09-11 14:42               ` Bastien
2012-12-05  8:04 ` bug#10056: 24.0.91; Mark deactivation Dani Moncayo
2012-12-08 10:09   ` Dani Moncayo
2012-12-08 23:03     ` Juri Linkov
2012-12-09  0:00       ` Drew Adams
2012-12-09  0:29         ` Juri Linkov
2012-12-09  3:21           ` Drew Adams
2012-12-09  9:07             ` Dani Moncayo
2013-01-25 12:34               ` Dani Moncayo
2013-01-25 17:41                 ` Drew Adams
2013-01-25 19:07                   ` Dani Moncayo
2013-01-25 19:34                     ` Drew Adams [this message]
2013-01-25 19:01                 ` Stefan Monnier
2022-04-26 13:50 ` bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Lars Ingebrigtsen

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=61EA87D1494E46E9AA03ACEDF88E7CD4@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=10056@debbugs.gnu.org \
    --cc=dmoncayo@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).