bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

Hello.

According to (info "(emacs)Text Registers"), the mark should be
deactivated at the end of the command `copy-to-register' (which is
TRT; `C-w' behaves that way, for example).

But I see that:
* The mark (region) remains active after doing "C-x h C-x r s s" (from
emacs -Q).
* The command's docstring does not mention anything about this. It should, no?


In GNU Emacs 24.0.91.1 (i386-mingw-nt6.1.7601)
 of 2011-11-11 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.5)'

-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

> But I see that:
> * The mark (region) remains active after doing "C-x h C-x r s s" (from
> emacs -Q).
> * The command's docstring does not mention anything about this. It should, no?

I see the same problem with `C-x r k' from a read-only buffer: it
should deactivate the mark, as C-w does.

-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

> According to (info "(emacs)Text Registers"), the mark should be
> deactivated at the end of the command `copy-to-register' (which is
> TRT; `C-w' behaves that way, for example).
        ^^^^

I meant `M-w', of course.

-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

>> But I see that:
>> * The mark (region) remains active after doing "C-x h C-x r s s" (from
>> emacs -Q).
>> * The command's docstring does not mention anything about this. It should, no?
>
> I see the same problem with `C-x r k' from a read-only buffer: it
> should deactivate the mark, as C-w does.

Same problem for `C-x r r'.


-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Chong Yidong]

Dani Moncayo <dmoncayo@gmail.com> writes:

> Hello.
>
> According to (info "(emacs)Text Registers"), the mark should be
> deactivated at the end of the command `copy-to-register' (which is
> TRT; `C-w' behaves that way, for example).
>
> But I see that:
> * The mark (region) remains active after doing "C-x h C-x r s s" (from
> emacs -Q).
> * The command's docstring does not mention anything about this. It should, no?

I agree that the mark should be deactivated.  But the current behavior
has been in place for a long time, so this change can probably wait till
after the release.

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

On Mon, Nov 21, 2011 at 7:30 AM, Chong Yidong <cyd@gnu.org> wrote:
> I agree that the mark should be deactivated.  But the current behavior
> has been in place for a long time, so this change can probably wait till
> after the release.

Ping.

Could this change[*] be made in the trunk, please?

[*] Deactivate the mark after some commands which save the region:
`copy-to-register', `copy-rectangle-to-register', `kill-rectangle'
(from a read-only buffer).

TIA.

-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

> I agree that the mark should be deactivated.  But the current behavior
> has been in place for a long time, so this change can probably wait till
> after the release.

Ping (again).

Summing up, I find annoying that the following commands currently
don't deactivate the mark at the end (when invoked in transient mark
mode, when the mark is active):
  copy-to-register
  copy-rectangle-to-register
  kill-rectangle (from a read-only buffer)

and I've found a couple more:
  narrow-to-region
  c-indent-line-or-region (when the region is already well indented)

TIA.

-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Chong Yidong]

Dani Moncayo <dmoncayo@gmail.com> writes:

> Ping (again).
>
> Summing up, I find annoying that the following commands currently
> don't deactivate the mark at the end (when invoked in transient mark
> mode, when the mark is active):
>   copy-to-register
>   copy-rectangle-to-register
>   kill-rectangle (from a read-only buffer)
>
> and I've found a couple more:
>   narrow-to-region
>   c-indent-line-or-region (when the region is already well indented)

Thanks for the remider.  I've changed copy-to-register and
copy-rectangle-to-register to deactivate the mark.

I left prepend-to-register and append-to-register alone for now; there
may be cases where users want to keep the mark active for those
commands, but I'm not certain.

As for C-x r k on read-only buffers, the mark is now deactivated, but
only if kill-read-only-ok is non-nil (similar to C-w).

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Chong Yidong]

Dani Moncayo <dmoncayo@gmail.com> writes:

> and I've found a couple more:
>   narrow-to-region
>   c-indent-line-or-region (when the region is already well indented)

I'm not sure about narrow-to-region.  It's probably wrong for it to
unconditionally deactivate the mark, because it is commonly called as a
Lisp function.  Maybe it should only deactivate the mark when called
interactively.

As for c-indent-line-or-region, I have no opinion on that at all.

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

> I left prepend-to-register and append-to-register alone for now; there
> may be cases where users want to keep the mark active for those
> commands, but I'm not certain.

I can't imagine such cases right now, but my imagination is limited :)

> As for C-x r k on read-only buffers, the mark is now deactivated, but
> only if kill-read-only-ok is non-nil (similar to C-w).

?? I don't see such behavior in a recent build of the trunk.  I've
just tested C-x r k (from Emacs -Q, in an Info buffer), and the mark
is not deactivated, even if kill-read-only-ok is non-nil.  IMO, the
mark should definitely be deactivated in this case.

And what is more, when kill-read-only-ok is nil, "C-x r k" still does
its job (despite the error message shown in the echo area), i.e., it
saves the rectangle contents.  Therefore, this is confusing from my
POV.  IMO, either the command should do nothing in this case (no
rectangle text gets saved), or, if the intention is to save the
rectangle also in this case, the mark should be deactivated, because
not doing so gives (me) the wrong impression, i.e, that the command
has been cancelled and nothing more happened.


-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

>> and I've found a couple more:
>>   narrow-to-region
>>   c-indent-line-or-region (when the region is already well indented)
>
> I'm not sure about narrow-to-region.  It's probably wrong for it to
> unconditionally deactivate the mark, because it is commonly called as a
> Lisp function.  Maybe it should only deactivate the mark when called
> interactively.

I will be happy if the deactivation is limited to the interactive
call.  But at least in this case should be deactivated, because it is
annoying to have to do the deactivation manually with C-g.

> As for c-indent-line-or-region, I have no opinion on that at all.

(I'm CC-ing Alan.  Hopefully he has an opinion) This is the current
behavior I observe:
* If the command has to adjust the indentation of some line(s) in the
region, the mark is deactivated at the end of the command.
* Else, the mark is not deactivated.

This behavior is definitely annoying for me: when I mark some fragment
of code and type TAB, what I want is that Emacs revise the indentation
of code, and correct it if necessary, but in any case, I don't want
the mark to remain active.

-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Alan Mackenzie]

Hi, Dani.

On Sun, Jul 29, 2012 at 12:01:51PM +0200, Dani Moncayo wrote:
> >> and I've found a couple more:
> >>   narrow-to-region
> >>   c-indent-line-or-region (when the region is already well indented)

> > I'm not sure about narrow-to-region.  It's probably wrong for it to
> > unconditionally deactivate the mark, because it is commonly called as a
> > Lisp function.  Maybe it should only deactivate the mark when called
> > interactively.

> I will be happy if the deactivation is limited to the interactive
> call.  But at least in this case should be deactivated, because it is
> annoying to have to do the deactivation manually with C-g.

> > As for c-indent-line-or-region, I have no opinion on that at all.

> (I'm CC-ing Alan.  Hopefully he has an opinion) This is the current
> behavior I observe:
> * If the command has to adjust the indentation of some line(s) in the
> region, the mark is deactivated at the end of the command.
> * Else, the mark is not deactivated.

> This behavior is definitely annoying for me: when I mark some fragment
> of code and type TAB, what I want is that Emacs revise the indentation
> of code, and correct it if necessary, but in any case, I don't want
> the mark to remain active.

Have you looked at the code for c-i-l-o-region?  At a quick glance, I
can't see where the distinction is made between indentation adjusted and
not adjusted.  I don't actually use transient-mark-mode myself, so this
hasn't annoyed me one way or the other.

Is the distinction there for a reason, or did it just get there by
accident?  The defun is only several (as opposed to many) years old, so
the evidence should still be available in the bzr repo.

> -- 
> Dani Moncayo

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

>> > As for c-indent-line-or-region, I have no opinion on that at all.
>
>> (I'm CC-ing Alan.  Hopefully he has an opinion) This is the current
>> behavior I observe:
>> * If the command has to adjust the indentation of some line(s) in the
>> region, the mark is deactivated at the end of the command.
>> * Else, the mark is not deactivated.
>
>> This behavior is definitely annoying for me: when I mark some fragment
>> of code and type TAB, what I want is that Emacs revise the indentation
>> of code, and correct it if necessary, but in any case, I don't want
>> the mark to remain active.
>
> Have you looked at the code for c-i-l-o-region? At a quick glance, I
> can't see where the distinction is made between indentation adjusted and
> not adjusted.  I don't actually use transient-mark-mode myself, so this
> hasn't annoyed me one way or the other.
>
> Is the distinction there for a reason, or did it just get there by
> accident?  The defun is only several (as opposed to many) years old, so
> the evidence should still be available in the bzr repo.

I'm sorry, I (still) don't have enough knowledge of Emacs to delve
into such questions.

I reported this bug as a mere user, hoping that you (the maintainers),
if agree with my reasoning, make the suitable changes to the program.

In the case at hand, what I reported is quite simple, I think: from
"emacs -Q" (transient mark mode on) visit some C file, select some
fragment of code and type TAB.

Hopefully you'll see the same behavior as me:
* If the code in the region was already well indented, nothing happens
and the mark remains active.
* Else, the code is indented and the mark is deactivated.

What I say is that the mark should be deactivated _always_ at the end
of the command, because the "transient" operation (revise the
indentation of those lines) is done.

This is so obvious to me that I'm surprised of seeing you so
hesitant...  but well, you decide :)

-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Alan Mackenzie]

Hi, Dani.

On Thu, Aug 02, 2012 at 12:07:06AM +0200, Dani Moncayo wrote:
> >> > As for c-indent-line-or-region, I have no opinion on that at all.

> >> (I'm CC-ing Alan.  Hopefully he has an opinion) This is the current
> >> behavior I observe:
> >> * If the command has to adjust the indentation of some line(s) in the
> >> region, the mark is deactivated at the end of the command.
> >> * Else, the mark is not deactivated.

> >> This behavior is definitely annoying for me: when I mark some fragment
> >> of code and type TAB, what I want is that Emacs revise the indentation
> >> of code, and correct it if necessary, but in any case, I don't want
> >> the mark to remain active.

> > Have you looked at the code for c-i-l-o-region? At a quick glance, I
> > can't see where the distinction is made between indentation adjusted and
> > not adjusted.  I don't actually use transient-mark-mode myself, so this
> > hasn't annoyed me one way or the other.

> > Is the distinction there for a reason, or did it just get there by
> > accident?  The defun is only several (as opposed to many) years old, so
> > the evidence should still be available in the bzr repo.

> I'm sorry, I (still) don't have enough knowledge of Emacs to delve
> into such questions.

> I reported this bug as a mere user, hoping that you (the maintainers),
> if agree with my reasoning, make the suitable changes to the program.

Sorry, misunderstanding on my part there.

> In the case at hand, what I reported is quite simple, I think: from
> "emacs -Q" (transient mark mode on) visit some C file, select some
> fragment of code and type TAB.

> Hopefully you'll see the same behavior as me:
> * If the code in the region was already well indented, nothing happens
> and the mark remains active.
> * Else, the code is indented and the mark is deactivated.

Yes, I see this.

> What I say is that the mark should be deactivated _always_ at the end
> of the command, because the "transient" operation (revise the
> indentation of those lines) is done.

> This is so obvious to me that I'm surprised of seeing you so
> hesitant...  but well, you decide :)

The hesitancy comes from long experience of Emacs; things which are so
obviously wrong to some are obviously the RT to others.  I was wondering
if this behaviour, strange though it seems to both of us, might have been
programmed deliberately.

In this case, there seems to be some bug at the lower levels of Emacs.
There is nothing in CC Mode I can find to explain this strange behaviour.
According to the elisp manual, the normal way of deactivating a region
when transient mark mode is enabled is to set the variable
`deactivate-mark', which instructs the command loop to do the business.

CC Mode doesn't set `deactivate-mark' at all.  Maybe some primitive does.
I don't really know transient-mark-mode.  Yidong, have you any
suggestions here?

> -- 
> Dani Moncayo

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Stefan Monnier]

>> This behavior is definitely annoying for me: when I mark some fragment
>> of code and type TAB, what I want is that Emacs revise the indentation
>> of code, and correct it if necessary, but in any case, I don't want
>> the mark to remain active.
> Have you looked at the code for c-i-l-o-region?  At a quick glance, I
> can't see where the distinction is made between indentation adjusted and
> not adjusted.

The way mark deactivation works is that the mark gets deactivated after
any command that modified the buffer (that's the basic heuristic used
to avoid having to change umpteen commands to explicitly deactivate-mark).
In the case of commands like indent-region which sometimes modify the
buffer and sometimes not, it's often necessary to explicitly call
deactivate-mark to avoid the kind of inconsistencies described above.


        Stefan

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Dani Moncayo]

> The way mark deactivation works is that the mark gets deactivated after
> any command that modified the buffer (that's the basic heuristic used
> to avoid having to change umpteen commands to explicitly deactivate-mark).

I think that the general principle for deactivating the mark is not
(and should not be) "after any command that modified the buffer", but
"after any command that _used_ the active region (for any purpose)".

For example, to copy some text on the kill ring, you select the text
and do C-w.  After that, the mark is deactivated.  The C-w command
doesn't modified the buffer, but _used_ the active region.  Thus,
after the operation on the active region is done, the mark must be
deactivated.  IMO, that is what the user wants/expects/needs, and
Emacs not always follows this principle.  Hence this bug report.

-- 
Dani Moncayo

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Bastien]

Dani Moncayo <dmoncayo@gmail.com> writes:

>> The way mark deactivation works is that the mark gets deactivated after
>> any command that modified the buffer (that's the basic heuristic used
>> to avoid having to change umpteen commands to explicitly deactivate-mark).
>
> I think that the general principle for deactivating the mark is not
> (and should not be) "after any command that modified the buffer", but
> "after any command that _used_ the active region (for any purpose)".

... unless it's immediately useful to reuse the active region?

But FWIW I agree in general. 

-- 
 Bastien

bug#10056: 24.0.91; Mark deactivation

[Dani Moncayo]

Hello,

As I pointed out previously in this thread, the mark should be
deactivated (in general - there can be some exceptions) after any
command that operates on the active region.  Not doing so is annoying,
because the mark must be deactivated in that cases manually by typing
`C-g'.

There are still cases where I observe this misbehavior.  Namely:

  kill-region [1]
  kill-rectangle [1]
  prepend-to-register
  append-to-register
  narrow-to-region [2]
  c-indent-line-or-region [3]
  delete-duplicate-lines [3]
  delete-matching-lines [3]
  delete-non-matching-lines [3]
  delete-blank-lines [3]


I hope this is fixed at some time.  Thanks.

--- Footnotes ---

[1] From a read-only buffer, having `kill-read-only-ok' set to nil.
Note that the command does its job in this case, but the mark still
remains active.  Not TRT IMO.
[2] According to Chong, in this case perhaps the mark deactivation
should be made only when the call is interactive.
[3] When the command doesn't alter the buffer text.

-- 
Dani Moncayo

bug#10056: 24.0.91; Mark deactivation

[Dani Moncayo]

> As I pointed out previously in this thread, the mark should be
> deactivated (in general - there can be some exceptions) after any
> command that operates on the active region.  Not doing so is annoying,
> because the mark must be deactivated in that cases manually by typing
> `C-g'.
>
> There are still cases where I observe this misbehavior.  Namely:
>
>   kill-region [1]
>   kill-rectangle [1]

>   prepend-to-register
>   append-to-register

I forgot to mention, for the two above commands, that the use case is
"when invoked with a prefix argument, from a read-only buffer."
(regardless of the value of `kill-read-only-ok', which doesn't seem to
have any effect on them).

>   narrow-to-region [2]
>   c-indent-line-or-region [3]
>   delete-duplicate-lines [3]
>   delete-matching-lines [3]
>   delete-non-matching-lines [3]
>   delete-blank-lines [3]

Add "fill-paragraph [3]" to the above list.  Important use-case.

> --- Footnotes ---
>
> [1] From a read-only buffer, having `kill-read-only-ok' set to nil.
> Note that the command does its job in this case, but the mark still
> remains active.  Not TRT IMO.
> [2] According to Chong, in this case perhaps the mark deactivation
> should be made only when the call is interactive.
> [3] When the command doesn't alter the buffer text.


-- 
Dani Moncayo

bug#10056: 24.0.91; Mark deactivation

[Juri Linkov]

>> As I pointed out previously in this thread, the mark should be
>> deactivated (in general - there can be some exceptions) after any
>> command that operates on the active region.  Not doing so is annoying,

The problem is how to implement a general rule "the mark should be
deactivated after any command that operates on the active region".
One way to define "operates on the active region" is when a command
uses `region-beginning' and `region-end'.  You can try this definition
by evaluating:

(defun deactivate-mark--advice () (setq deactivate-mark t))
(advice-add 'region-beginning :after #'deactivate-mark--advice)
(advice-add 'region-end       :after #'deactivate-mark--advice)

Does this do what you want with the following functions?

>> There are still cases where I observe this misbehavior.  Namely:
>>
>>   kill-region [1]
>>   kill-rectangle [1]
>>   prepend-to-register
>>   append-to-register
>>   narrow-to-region [2]
>>   c-indent-line-or-region [3]
>>   delete-duplicate-lines [3]
>>   delete-matching-lines [3]
>>   delete-non-matching-lines [3]
>>   delete-blank-lines [3]
>
> Add "fill-paragraph [3]" to the above list.  Important use-case.

Does this have a side effect undesirable for other functions?

bug#10056: 24.0.91; Mark deactivation

[Drew Adams]

> >> As I pointed out previously in this thread, the mark should be
> >> deactivated (in general - there can be some exceptions) after any
> >> command that operates on the active region.  Not doing so 
> >> is annoying,
> 
> The problem is how to implement a general rule "the mark should be
> deactivated after any command that operates on the active region".

To me, the question is why we would do that, and even what the latter part
means.

> One way to define "operates on the active region" is when a command
> uses `region-beginning' and `region-end'.  You can try this definition
> by evaluating:
> (defun deactivate-mark--advice () (setq deactivate-mark t))
> (advice-add 'region-beginning :after #'deactivate-mark--advice)
> (advice-add 'region-end       :after #'deactivate-mark--advice)
> Does this do what you want with the following functions?
> ...
> Does this have a side effect undesirable for other functions?

Please think again before doing this.  "Operates on the active region" can mean
just about anything, and I fear that such a blanket manipulation will have
adverse affects here and there.

And I expect in particular that any use of either `region-beginning' or
`region-end' casts the net far too wide.  Those functions are often used without
making any changes to the text in the region (or even in the buffer). 

For one thing, any such blanket change would still need to respect (not
override) a commands's explicit setting or let-binding of `deactivate-mark'.

This has been the of policy ever since there was a notion of mark "activeness"
(i.e., since `transient-mark-mode'):

 -- Variable: deactivate-mark
     If an editor command sets this variable non-`nil', then the editor
     command loop deactivates the mark after the command returns (if
     Transient Mark mode is enabled).  All the primitives that change
     the buffer set `deactivate-mark', to deactivate the mark when the
     command is finished.

     To write Lisp code that modifies the buffer without causing
     deactivation of the mark at the end of the command, bind
     `deactivate-mark' to `nil' around the code that does the
     modification.  For example:

          (let (deactivate-mark) (insert " "))

I, and I'm sure others too, have a certain amount of code that binds or sets
`deactivate-mark'.  Just grep the Emacs Lisp sources for examples.

There are commands that use the region and are used as functions within other
commands.  There are commands that can be used repetitively and might expect to
leave the region active between successive calls.  There are commands whose
purpose is to set the active region.  Emacs is complex, and one size does not
fit all for this kind of thing.

If  for some reason a particular Emacs command does not deactivate the mark when
it is finished, but you think it should, then just deactivate it explicitly in
that command.

Just because you find some commands that should but do not yet do so is not a
sufficient reason to try forcing this everywhere.

Someone took the time to ensure that "All the primitives that change the buffer"
DTRT in this regard, and that the command loop respects `deactivate-mark'.  You
have only to continue that policy carefully: if deactivating (or activating)
needs doing here or there, then do it here or there, case by case.

Otherwise, I think you're asking for trouble.  I could be wrong, of course.  But
it seems a bit heavy-handed to set out on such a crusade just because this or
that command might need fixing.  Let's try first to fix (only) the commands that
Dani or others report such have a problem.

bug#10056: 24.0.91; Mark deactivation

[Juri Linkov]

> Let's try first to fix (only) the commands that Dani
> or others report such have a problem.

That means adding `(setq deactivate-mark t)' to some functions,
but this is not user-configurable.  Maybe like delsel.el puts
the property `delete-selection' on some functions, we should use
the property `deactivate-mark', e.g.:

(put 'fill-paragraph 'deactivate-mark t)

bug#10056: 24.0.91; Mark deactivation

[Drew Adams]

> > Let's try first to fix (only) the commands that Dani
> > or others report such have a problem.
> 
> That means adding `(setq deactivate-mark t)' to some functions,
> but this is not user-configurable.

What is not user-configurable?  Why should it be user-configurable whether a
command activates or deactivates the mark?  Where is that user-configurable
today?

And if Emacs Dev decides that standard command foo should deactivate the mark
when done, but some user wants it to activate the mark (but why?), then s?he can
define a command foo' that calls foo and then deactivates the mark.

My impression is that you are inventing a problem where there is none.  But
perhaps I am missing something.  Just what is the problem you are trying to
solve?

> Maybe like delsel.el puts
> the property `delete-selection' on some functions, we should use
> the property `deactivate-mark', e.g.:
> 
> (put 'fill-paragraph 'deactivate-mark t)

YAGNI.  What problem are you looking to solve?

(And BTW, when you grep for `deactivate-mark' you will notice that delsel.el is
one of the libraries with a function that explicitly sets that variable.)

bug#10056: 24.0.91; Mark deactivation

[Dani Moncayo]

Thanks to both of you for taking time to think and debate about this.

I don't feel qualified enough to have an opinion on which approach is
better for fixing this.

Drew's proposal (deactivate the mark in a case-by-case basis) seems
less general but safer/easier than Juri's in the short-term.

Maybe we could take the easy route for now, and perhaps do a refactoring later.

-- 
Dani Moncayo

bug#10056: 24.0.91; Mark deactivation

[Dani Moncayo]

I've just noticed a new case where the mark is not deactivated, when
it clearly should (IMO): after `eval-region'.

So this is the updated list:
  eval-region
  kill-region [1]
  kill-rectangle [1]
  prepend-to-register [4]
  append-to-register [4]
  narrow-to-region [2]
  fill-paragraph [3]
  c-indent-line-or-region [3]
  delete-duplicate-lines [3]
  delete-matching-lines [3]
  delete-non-matching-lines [3]
  delete-blank-lines [3]


--- Footnotes ---

[1] From a read-only buffer, having `kill-read-only-ok' set to nil.
Note that the command does its job in this case, but the mark still
remains active.  Not TRT IMO.

[2] According to Chong, in this case perhaps the mark deactivation
should be made only when the call is interactive.

[3] When the command doesn't alter the buffer text.

[4] When invoked with a prefix argument, from a read-only buffer
(regardless of the value of  `kill-read-only-ok', which doesn't seem
to have any effect on them).

-- 
Dani Moncayo

bug#10056: 24.0.91; Mark deactivation

[Drew Adams]

> I've just noticed a new case where the mark is not deactivated, when
> it clearly should (IMO): after `eval-region'.

Why should it?

Even when used interactively (and certainly when not!), a user can want to do
something else with the active region after evaluating it.

Yes, s?he can always hit `C-x C-x C-x C-x' to reactivate it (there is probably a
shorter way to do it nowadays, but I still have that habit).  But the question
is why?  What's the reason to deactivate the region after `eval-region'?

To be clear, I have no particular objection that I can think of offhand.  But I
don't see why the behavior should be changed.  "If it ain't broke don't fix it."
IOW, please argue a bit in favor of the change for this specific command - some
reasons, please.

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

bug#10056: 24.0.91; Mark deactivation

[Stefan Monnier]

I agree with the idea that those commands should be thought of as
"consuming" the region, so they should deactivate the mark even if the
buffer is not modified.

> [2] According to Chong, in this case perhaps the mark deactivation
> should be made only when the call is interactive.

Right, obviously when called non-interactively, they should take
BEG..END arguments, and these are not necessarily related to the region,
so they should deactivate the mark if they indeed used it to figure out
the BEG..END, i.e. when called interactively.


        Stefan

bug#10056: 24.0.91; Mark deactivation

[Dani Moncayo]

On Fri, Jan 25, 2013 at 6:41 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> I've just noticed a new case where the mark is not deactivated, when
>> it clearly should (IMO): after `eval-region'.
>
> Why should it?
>
> Even when used interactively (and certainly when not!),

I'm concerned about _interactive_ usability.  Sorry if I didn't make
that clear before.

> a user can want to do
> something else with the active region after evaluating it.
>
> Yes, s?he can always hit `C-x C-x C-x C-x' to reactivate it (there is probably a
> shorter way to do it nowadays, but I still have that habit).  But the question
> is why?  What's the reason to deactivate the region after `eval-region'?
>
> To be clear, I have no particular objection that I can think of offhand.  But I
> don't see why the behavior should be changed.  "If it ain't broke don't fix it."
> IOW, please argue a bit in favor of the change for this specific command - some
> reasons, please.

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.

> 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".
But, well, I'm thinking that perhaps the mark deactivation I'm
requesting should be specific to interactive calls.  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.

-- 
Dani Moncayo

bug#10056: 24.0.91; Mark deactivation

[Drew Adams]

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

bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark

[Lars Ingebrigtsen]

Dani Moncayo <dmoncayo@gmail.com> writes:

> According to (info "(emacs)Text Registers"), the mark should be
> deactivated at the end of the command `copy-to-register' (which is
> TRT; `C-w' behaves that way, for example).
>
> But I see that:
> * The mark (region) remains active after doing "C-x h C-x r s s" (from
> emacs -Q).
> * The command's docstring does not mention anything about this. It should, no?

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Chong fixed this at the time, but the discussion then went on to whether
other commands, like `eval-region' should do the same.  The rough
consensus seemed to be "nope", and I think that's the right decision, so
I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no