bug#20357: 25.0.50; deactivate-mark behavior broken

bug#20357: 25.0.50; deactivate-mark behavior broken

[Oleh Krehel]

This is a recent change, 24.5.2 doesn't have this bug.

How to reproduce:

1. Mark some text.
2. Call this:

(let (deactivate-mark)
  (indent-region (region-beginning)
                 (region-end)))

Expected behavior: the mark isn't deactivated.

Actual behavior: the mark is deactivated.

bug#20357: 25.0.50; deactivate-mark behavior broken

[Stefan Monnier]

> (let (deactivate-mark)
>   (indent-region (region-beginning)
>                  (region-end)))
> Expected behavior: the mark isn't deactivated.
> Actual behavior: the mark is deactivated.

Oops, indeed.  Fixed with the patch below,


        Stefan


diff --git a/lisp/indent.el b/lisp/indent.el
index 74e73a6..18c1fd4 100644
--- a/lisp/indent.el
+++ b/lisp/indent.el
@@ -537,7 +537,7 @@ column to indent to; if it is nil, use one of the three methods above."
   ;; In most cases, reindenting modifies the buffer, but it may also
   ;; leave it unmodified, in which case we have to deactivate the mark
   ;; by hand.
-  (deactivate-mark))
+  (setq deactivate-mark t))
 
 (defun indent-relative-maybe ()
   "Indent a new line like previous nonblank line.

bug#20357: 25.0.50; deactivate-mark behavior broken

[Oleh Krehel]

Hi Stefan,

On Fri, Apr 17, 2015 at 4:31 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> (let (deactivate-mark)
>>   (indent-region (region-beginning)
>>                  (region-end)))
>> Expected behavior: the mark isn't deactivated.
>> Actual behavior: the mark is deactivated.
>
> Oops, indeed.  Fixed with the patch below,
>
> diff --git a/lisp/indent.el b/lisp/indent.el
> index 74e73a6..18c1fd4 100644
> --- a/lisp/indent.el
> +++ b/lisp/indent.el
> @@ -537,7 +537,7 @@ column to indent to; if it is nil, use one of the three methods above."
>    ;; In most cases, reindenting modifies the buffer, but it may also
>    ;; leave it unmodified, in which case we have to deactivate the mark
>    ;; by hand.
> -  (deactivate-mark))
> +  (setq deactivate-mark t))
>
>  (defun indent-relative-maybe ()
>    "Indent a new line like previous nonblank line.

This is still not the correct behavior. Example code:

(with-temp-buffer
  (insert "foobar")
  (set-mark (point))
  (goto-char (point-min))
  (indent-region (point-min)
                 (point-max))
  mark-active)

In 24.5 it returns nil, which is correct. While in 25 it returns t.

Oleh

bug#20357: 25.0.50; deactivate-mark behavior broken

[Stefan Monnier]

> (with-temp-buffer
>   (insert "foobar")
>   (set-mark (point))
>   (goto-char (point-min))
>   (indent-region (point-min)
>                  (point-max))
>   mark-active)
> In 24.5 it returns nil, which is correct. While in 25 it returns t.

Why is it more correct to return nil than to return t?

> This is a recent change, 24.5.2 doesn't have this bug.
>
> (let (deactivate-mark)
>   (indent-region (region-beginning)
>                  (region-end)))
>
> Expected behavior: the mark isn't deactivated.

At least in 24.4, the mark does get deactivated in my test.


        Stefan

bug#20357: 25.0.50; deactivate-mark behavior broken

[Oleh Krehel]

On Fri, Apr 17, 2015 at 8:22 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> (with-temp-buffer
>>   (insert "foobar")
>>   (set-mark (point))
>>   (goto-char (point-min))
>>   (indent-region (point-min)
>>                  (point-max))
>>   mark-active)
>> In 24.5 it returns nil, which is correct. While in 25 it returns t.
>
> Why is it more correct to return nil than to return t?

Because it's a long standing behavior that if you mark some stuff and
press TAB, the mark will be deactivated.  And in 25, the mark actually
is deactivated outside of temp buffers, which is where I run my ERT
tests. So the tests are passing for 24.5 and failing for 25, while the
functions actually do work in both.

>
>> This is a recent change, 24.5.2 doesn't have this bug.
>>
>> (let (deactivate-mark)
>>   (indent-region (region-beginning)
>>                  (region-end)))
>>
>> Expected behavior: the mark isn't deactivated.
>
> At least in 24.4, the mark does get deactivated in my test.

This may be possible. Previously, I was testing using the emacs24 ppa
install, that uses emacs-24.3.
I've started testing with emacs-snapshot only this week, and the tests
started failing.
But when I've tested with 24.5 or 25 on my own machine, the tests were
running fine.

Oleh

bug#20357: 25.0.50; deactivate-mark behavior broken

[Stefan Monnier]

>>> (with-temp-buffer
>>> (insert "foobar")
>>> (set-mark (point))
>>> (goto-char (point-min))
>>> (indent-region (point-min)
>>> (point-max))
>>> mark-active)
>>> In 24.5 it returns nil, which is correct. While in 25 it returns t.
>> Why is it more correct to return nil than to return t?
> Because it's a long standing behavior that if you mark some stuff and
> press TAB, the mark will be deactivated.

That's still the case.  The difference is that now it's deactivated by
the command loop rather than by the command itself.  Doing it in the
command loop is the normal behavior (the one used for most other
commands which cause the mark to be deactivated).

>>> This is a recent change, 24.5.2 doesn't have this bug.
>>> (let (deactivate-mark)
>>>   (indent-region (region-beginning)
>>>                  (region-end)))
>>> Expected behavior: the mark isn't deactivated.
>> At least in 24.4, the mark does get deactivated in my test.

It's also deactivated in Emacs-23.4 in my tests.

> But when I've tested with 24.5 or 25 on my own machine, the tests were
> running fine.

I think we need to know more about what your tests really do.
Maybe they should just be fixed to test (or (not mark-active)
deactivate-mark) instead of only testing mark-active.


        Stefan