bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10056: 24.0.91; Mark deactivation


From: Drew Adams
Subject: bug#10056: 24.0.91; Mark deactivation
Date: Fri, 25 Jan 2013 11:34:18 -0800

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]