bug#22338: 25.0.50; deactivate-mark regression

bug#22338: 25.0.50; deactivate-mark regression

[Leo Liu]

1. Emacs -q
2. Open a file and mark an active region
3. (revert-buffer nil t t)

The mark is still active after the buffer revert. This isn't the case
for emacs 24.5.

The trouble is if the file has changed on disk (e.g. by another process
such as vim), the mark is still active after the revert.

Leo

bug#22338: 25.0.50; deactivate-mark regression

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Sat, 09 Jan 2016 23:39:37 +0800
> 
> 1. Emacs -q
> 2. Open a file and mark an active region
> 3. (revert-buffer nil t t)
> 
> The mark is still active after the buffer revert. This isn't the case
> for emacs 24.5.

When I try this with different files and different changes actually
made to the file behind Emacs's back, I see the region deactivate
every time I revert and the file on disk was really changed.  Maybe it
doesn't always deactivate the region, but it certainly doesn't always
keep it active, except when the file on disk didn't change at all.

Do you really see the region remain active every revert, no matter
what the changes to the file on disk?  Can you show a detailed recipe
for that?

Anyway, since the documentation never says what will happen with the
region, I tend to consider this behavior unspecified: why should Lisp
programs expect anything specific to happen to the region during a
revert?

> The trouble is if the file has changed on disk (e.g. by another process
> such as vim), the mark is still active after the revert.

Why is that trouble?

Thanks.

bug#22338: 25.0.50; deactivate-mark regression

[Leo Liu]

On 2016-01-16 10:24 +0200, Eli Zaretskii wrote:
> When I try this with different files and different changes actually
> made to the file behind Emacs's back, I see the region deactivate
> every time I revert and the file on disk was really changed.  Maybe it
> doesn't always deactivate the region, but it certainly doesn't always
> keep it active, except when the file on disk didn't change at all.
>
> Do you really see the region remain active every revert, no matter
> what the changes to the file on disk?  Can you show a detailed recipe
> for that?
>
> Anyway, since the documentation never says what will happen with the
> region, I tend to consider this behavior unspecified: why should Lisp
> programs expect anything specific to happen to the region during a
> revert?

How did you revert? C-x C-v or eval (revert-buffer nil t t)? For me the
latter always keeps the region active in 25.0.50 (built on 02 Jan 2016).

>> The trouble is if the file has changed on disk (e.g. by another process
>> such as vim), the mark is still active after the revert.
>
> Why is that trouble?
>
> Thanks.

The trouble is now users have no idea what the active region is. For
example I've experienced reverts that change the active region to cover
nearly the whole buffer. The sane behaviour seems to have the active
region off after revert just like in emacs 24.x.

Leo

bug#22338: 25.0.50; deactivate-mark regression

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Thu, 21 Jan 2016 18:13:36 +0800
> 
> How did you revert? C-x C-v or eval (revert-buffer nil t t)?

The latter, of course.

> For me the latter always keeps the region active in 25.0.50 (built
> on 02 Jan 2016).

My build is more current, but I don't think anything's changed since
Jan 2.

Would you mind showing a more detailed recipe, including the file you
used and the exact procedure to change the file behind Emacs's back?
Also, how do you check that the mark is still active after the revert?
I feel there are some fine details that are different between our
attempts to reproduce the issue, because I cannot reproduce it no
matter what I do.  There's some factor here that I don't get.  I hope
it's not some stupid oversight on my part.

> The trouble is now users have no idea what the active region is. For
> example I've experienced reverts that change the active region to cover
> nearly the whole buffer.

Well, if we are talking about users, why would a user invoke
revert-buffer in such a strange way?  And if the region is active, but
not highlighted, doesn't "C-x C-x" show it highlighted?

Anyway, let's delay this discussion until we understand what exactly
is needed to reproduce the issue.

Thanks.

bug#22338: 25.0.50; deactivate-mark regression

[Leo Liu]

On 2016-01-21 18:08 +0200, Eli Zaretskii wrote:
> Would you mind showing a more detailed recipe, including the file you
> used and the exact procedure to change the file behind Emacs's back?
> Also, how do you check that the mark is still active after the revert?
> I feel there are some fine details that are different between our
> attempts to reproduce the issue, because I cannot reproduce it no
> matter what I do.  There's some factor here that I don't get.  I hope
> it's not some stupid oversight on my part.

I am now using GNU Emacs 25.0.90 built on 2016-01-31 and the problem
seems getting better. My current observation is this (revert-buffer nil
t t) only keeps the active mark if the file has not changed at all but
deactivates it otherwise. I modified the file by appending a line to it
using shell command.

> Well, if we are talking about users, why would a user invoke
> revert-buffer in such a strange way?  And if the region is active, but
> not highlighted, doesn't "C-x C-x" show it highlighted?

Obviously not directly. It can be part of a hook. For example I am using
a package to refactor erlang which writes to disk and send emacs the
list of files that may have changed.

HTH,
Leo

bug#22338: 25.0.50; deactivate-mark regression

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Mon, 01 Feb 2016 19:02:08 +0800
> 
> I am now using GNU Emacs 25.0.90 built on 2016-01-31 and the problem
> seems getting better. My current observation is this (revert-buffer nil
> t t) only keeps the active mark if the file has not changed at all but
> deactivates it otherwise. I modified the file by appending a line to it
> using shell command.

This is exactly what I did, and your observations now match mine.

Do you still think the mark should be deactivated in that single case,
or can we conclude that the problem is no longer significant and close
this bug?

Thanks.

bug#22338: 25.0.50; deactivate-mark regression

[Leo Liu]

On 2016-02-01 21:08 +0200, Eli Zaretskii wrote:
> This is exactly what I did, and your observations now match mine.
>
> Do you still think the mark should be deactivated in that single case,
> or can we conclude that the problem is no longer significant and close
> this bug?
>
> Thanks.

Yes I think that's the right thing to do. Will close it in a few days.

Thanks, Leo.

bug#22338: 25.0.50; deactivate-mark regression

[Lars Ingebrigtsen]

Leo Liu <sdl.web@gmail.com> writes:

> On 2016-02-01 21:08 +0200, Eli Zaretskii wrote:
>> This is exactly what I did, and your observations now match mine.
>>
>> Do you still think the mark should be deactivated in that single case,
>> or can we conclude that the problem is no longer significant and close
>> this bug?
>>
>> Thanks.
>
> Yes I think that's the right thing to do. Will close it in a few days.

That was two weeks ago...  is this OK now?

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

bug#22338: 25.0.50; deactivate-mark regression

[Leo Liu]

On 2016-02-16 18:06 +1100, Lars Ingebrigtsen wrote:
> That was two weeks ago...  is this OK now?

Sorry there is a Spring Festival break.

The bug is still there however I can only reproduce this with a local
setup involving Erlang + wrangler + emacs (24.5, 25.0.91). I need time
to find a recipe to reproduce it.

Cheers,
Leo

bug#22338: 25.0.50; deactivate-mark regression

[Leo Liu]

On 2016-02-16 15:27 +0800, Leo Liu wrote:
> The bug is still there however I can only reproduce this with a local
> setup involving Erlang + wrangler + emacs (24.5, 25.0.91).

I have found a recipe to partially reproduce the bug.

1. start emacs -Q
2. define a command

   (defun test ()
     (interactive)
     (shell-command (format "echo 'test' >> %s" buffer-file-name))
     (revert-buffer nil t t))

3. Open a file, mark an active region and M-x test

You should observe the mark stay active. The active region goes off
after 2 seconds. In emacs 24.5 the mark will go off immediately. With my
local setup the active region stays on. Thus I am calling this recipe
``partial''.

I wonder if it helps understand the issue.

Leo

bug#22338: 25.0.50; deactivate-mark regression

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Thu, 18 Feb 2016 18:14:42 +0800
> 
> On 2016-02-16 15:27 +0800, Leo Liu wrote:
> > The bug is still there however I can only reproduce this with a local
> > setup involving Erlang + wrangler + emacs (24.5, 25.0.91).
> 
> I have found a recipe to partially reproduce the bug.
> 
> 1. start emacs -Q
> 2. define a command
> 
>    (defun test ()
>      (interactive)
>      (shell-command (format "echo 'test' >> %s" buffer-file-name))
>      (revert-buffer nil t t))
> 
> 3. Open a file, mark an active region and M-x test
> 
> You should observe the mark stay active. The active region goes off
> after 2 seconds. In emacs 24.5 the mark will go off immediately. With my
> local setup the active region stays on. Thus I am calling this recipe
> ``partial''.
> 
> I wonder if it helps understand the issue.

Not really.  In "emacs -Q", the region is deactivated by the command
loop, when it notices that the variable deactivate-mark is non-nil.
It is non-nil because the buffer was modified.  So this sounds like
Emacs working as designed to me.  In Emacs 24.5, the region is
deactivated by the same code for the same reason.  I don't know why in
24.5 this happens immediately, whereas in 25.0 it takes an extra
second (my guess is this is related to redisplay, and perhaps also to
the changed implementation of displaying the region).

bug#22338: 25.0.50; deactivate-mark regression

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Not really.  In "emacs -Q", the region is deactivated by the command
> loop, when it notices that the variable deactivate-mark is non-nil.
> It is non-nil because the buffer was modified.  So this sounds like
> Emacs working as designed to me. 

Sounds like that to me, too, so I'm closing this bug report.

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