Apparent regression on the undo command

Apparent regression on the undo command

[Artur Malabarba]

I've been noticing this for days now. Whenever I invoke `undo' (C-/),
the last change is correctly undone but then sometimes the cursor gets
moved apparently random places in the buffer.

It took me a couple of days to realise it was moving point to the
position of my "penultimate" change (the change before the one I just
undid).

Is this intentional? I don't see anything about on the NEWS.
If so, is there a way to disable it?


Cheers,
Artur

Re: Apparent regression on the undo command

[Phillip Lord]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> I've been noticing this for days now. Whenever I invoke `undo' (C-/),
> the last change is correctly undone but then sometimes the cursor gets
> moved apparently random places in the buffer.
>
> It took me a couple of days to realise it was moving point to the
> position of my "penultimate" change (the change before the one I just
> undid).
>
> Is this intentional? I don't see anything about on the NEWS.
> If so, is there a way to disable it?

Almost certainly my fault, and caused by commit 44dfa86b7.

Anything that you can do to make it repeatable would be excellent. If
you cannot make it repeatable, it would be good to know that also.

Also, can you try:

(setq undo-auto--current-boundary-timer t)

and see if that stops it.

Phil

Re: Apparent regression on the undo command

[Artur Malabarba]

> Anything that you can do to make it repeatable would be excellent. If
> you cannot make it repeatable, it would be good to know that also.

1. Start emacs -Q
2. Delete the word "buffer"
3. Move up a couple of lines, and delete the word "want".
4. undo
5. Point will be left at where you deleted the word "buffer".

> Also, can you try:
>
> (setq undo-auto--current-boundary-timer t)
>
> and see if that stops it.

No. Still same thing.


Best,

Re: Apparent regression on the undo command

[Phillip Lord]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> Anything that you can do to make it repeatable would be excellent. If
>> you cannot make it repeatable, it would be good to know that also.
>
> 1. Start emacs -Q
> 2. Delete the word "buffer"
> 3. Move up a couple of lines, and delete the word "want".
> 4. undo
> 5. Point will be left at where you deleted the word "buffer".
>
>> Also, can you try:
>>
>> (setq undo-auto--current-boundary-timer t)
>>
>> and see if that stops it.
>
> No. Still same thing.


So, I've tested, and this problem is not caused by patch after all, but
sometime since 24.5. I'll try and see if I can automate the problem and
run a bisect.

Phil

Re: Apparent regression on the undo command

[Artur Malabarba]

2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
> I'll try and see if I can automate the problem and
> run a bisect.

The following works for me. When called on the *scratch* buffer it
returns non-nil if the problem occurs.

(progn
  (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
  (equal (point-min) (point)))

That macro simply calls M-< C-k C-n C-n C-k C-/

Re: Apparent regression on the undo command

[Phillip Lord]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>> I'll try and see if I can automate the problem and
>> run a bisect.
>
> The following works for me. When called on the *scratch* buffer it
> returns non-nil if the problem occurs.
>
> (progn
>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
>   (equal (point-min) (point)))
>
> That macro simply calls M-< C-k C-n C-n C-k C-/


I tried various combinations -- works interactively but fails in batch
either because *scratch* hasn't been initialized, or undo appears to
work wrongly.

No worries, it's easy enough to test by hand, and am doing so.

Phil

Re: Apparent regression on the undo command

[Karl Fogel]

phillip.lord@russet.org.uk (Phillip Lord) writes:
>Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>>> I'll try and see if I can automate the problem and
>>> run a bisect.
>>
>> The following works for me. When called on the *scratch* buffer it
>> returns non-nil if the problem occurs.
>>
>> (progn
>>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
>>   (equal (point-min) (point)))
>>
>> That macro simply calls M-< C-k C-n C-n C-k C-/
>
>
>I tried various combinations -- works interactively but fails in batch
>either because *scratch* hasn't been initialized, or undo appears to
>work wrongly.
>
>No worries, it's easy enough to test by hand, and am doing so.

Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from commit c210b8b128c.

Best regards,
-Karl

RE: Apparent regression on the undo command

[Phillip Lord]

It is my commit after all. I will work on it as soon as I can. Had a nasty cold for the last few days.

Phil
________________________________________
From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of Karl Fogel [kfogel@red-bean.com]
Sent: 20 November 2015 01:24
To: Phillip Lord
Cc: Artur Malabarba; emacs-devel
Subject: Re: Apparent regression on the undo command

phillip.lord@russet.org.uk (Phillip Lord) writes:
>Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>>> I'll try and see if I can automate the problem and
>>> run a bisect.
>>
>> The following works for me. When called on the *scratch* buffer it
>> returns non-nil if the problem occurs.
>>
>> (progn
>>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
>>   (equal (point-min) (point)))
>>
>> That macro simply calls M-< C-k C-n C-n C-k C-/
>
>
>I tried various combinations -- works interactively but fails in batch
>either because *scratch* hasn't been initialized, or undo appears to
>work wrongly.
>
>No worries, it's easy enough to test by hand, and am doing so.

Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from commit c210b8b128c.

Best regards,
-Karl

RE: Apparent regression on the undo command

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

No problem Phil.
Thanks for looking into this.
On 20 Nov 2015 7:51 am, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:

>
> It is my commit after all. I will work on it as soon as I can. Had a nasty
> cold for the last few days.
>
> Phil
> ________________________________________
> From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org
> [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of
> Karl Fogel [kfogel@red-bean.com]
> Sent: 20 November 2015 01:24
> To: Phillip Lord
> Cc: Artur Malabarba; emacs-devel
> Subject: Re: Apparent regression on the undo command
>
> phillip.lord@russet.org.uk (Phillip Lord) writes:
> >Artur Malabarba <bruce.connor.am@gmail.com> writes:
> >> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
> >>> I'll try and see if I can automate the problem and
> >>> run a bisect.
> >>
> >> The following works for me. When called on the *scratch* buffer it
> >> returns non-nil if the problem occurs.
> >>
> >> (progn
> >>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
> >>   (equal (point-min) (point)))
> >>
> >> That macro simply calls M-< C-k C-n C-n C-k C-/
> >
> >
> >I tried various combinations -- works interactively but fails in batch
> >either because *scratch* hasn't been initialized, or undo appears to
> >work wrongly.
> >
> >No worries, it's easy enough to test by hand, and am doing so.
>
> Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from
> commit c210b8b128c.
>
> Best regards,
> -Karl
>
>

[-- Attachment #2: Type: text/html, Size: 2315 bytes --]

Re: Apparent regression on the undo command

[Phillip Lord]

I have a possible fix for this now, currently on the
branch fix/undo-point-in-wrong-place. I waiting for some other feedback
on my code before I squash and merge it, but if you have the chance it
would be good to know if it works.

Phil


Artur Malabarba <bruce.connor.am@gmail.com> writes:

> No problem Phil.
> Thanks for looking into this.
> On 20 Nov 2015 7:51 am, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:
>
>>
>> It is my commit after all. I will work on it as soon as I can. Had a nasty
>> cold for the last few days.
>>
>> Phil
>> ________________________________________
>> From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org
>> [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of
>> Karl Fogel [kfogel@red-bean.com]
>> Sent: 20 November 2015 01:24
>> To: Phillip Lord
>> Cc: Artur Malabarba; emacs-devel
>> Subject: Re: Apparent regression on the undo command
>>
>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>> >Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> >> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>> >>> I'll try and see if I can automate the problem and
>> >>> run a bisect.
>> >>
>> >> The following works for me. When called on the *scratch* buffer it
>> >> returns non-nil if the problem occurs.
>> >>
>> >> (progn
>> >>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
>> >>   (equal (point-min) (point)))
>> >>
>> >> That macro simply calls M-< C-k C-n C-n C-k C-/
>> >
>> >
>> >I tried various combinations -- works interactively but fails in batch
>> >either because *scratch* hasn't been initialized, or undo appears to
>> >work wrongly.
>> >
>> >No worries, it's easy enough to test by hand, and am doing so.
>>
>> Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from
>> commit c210b8b128c.
>>
>> Best regards,
>> -Karl
>>
>>

Re: Apparent regression on the undo command

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

I can't speak for the code, but I just tested your fix and looks like it
works.

Thanks Phil.

2015-11-21 10:02 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:

>
> I have a possible fix for this now, currently on the
> branch fix/undo-point-in-wrong-place. I waiting for some other feedback
> on my code before I squash and merge it, but if you have the chance it
> would be good to know if it works.
>
> Phil
>
>
> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
> > No problem Phil.
> > Thanks for looking into this.
> > On 20 Nov 2015 7:51 am, "Phillip Lord" <phillip.lord@newcastle.ac.uk>
> wrote:
> >
> >>
> >> It is my commit after all. I will work on it as soon as I can. Had a
> nasty
> >> cold for the last few days.
> >>
> >> Phil
> >> ________________________________________
> >> From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org
> >> [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of
> >> Karl Fogel [kfogel@red-bean.com]
> >> Sent: 20 November 2015 01:24
> >> To: Phillip Lord
> >> Cc: Artur Malabarba; emacs-devel
> >> Subject: Re: Apparent regression on the undo command
> >>
> >> phillip.lord@russet.org.uk (Phillip Lord) writes:
> >> >Artur Malabarba <bruce.connor.am@gmail.com> writes:
> >> >> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
> >> >>> I'll try and see if I can automate the problem and
> >> >>> run a bisect.
> >> >>
> >> >> The following works for me. When called on the *scratch* buffer it
> >> >> returns non-nil if the problem occurs.
> >> >>
> >> >> (progn
> >> >>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
> >> >>   (equal (point-min) (point)))
> >> >>
> >> >> That macro simply calls M-< C-k C-n C-n C-k C-/
> >> >
> >> >
> >> >I tried various combinations -- works interactively but fails in batch
> >> >either because *scratch* hasn't been initialized, or undo appears to
> >> >work wrongly.
> >> >
> >> >No worries, it's easy enough to test by hand, and am doing so.
> >>
> >> Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from
> >> commit c210b8b128c.
> >>
> >> Best regards,
> >> -Karl
> >>
> >>
>

[-- Attachment #2: Type: text/html, Size: 3510 bytes --]

bug#21968: Apparent regression on the undo command

[David Reitter]

Phil,

I tried your fix.  It works for backward-kill-word, but for kill-word (forward), the cursor ends up in the wrong place (after the word, not where it was initially).

- David


> On Nov 21, 2015, at 6:18 AM, Artur Malabarba <bruce.connor.am@gmail.com> wrote:
> 
> I can't speak for the code, but I just tested your fix and looks like it works.
> 
> Thanks Phil.
> 
> 2015-11-21 10:02 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
> 
> I have a possible fix for this now, currently on the
> branch fix/undo-point-in-wrong-place. I waiting for some other feedback
> on my code before I squash and merge it, but if you have the chance it
> would be good to know if it works.
> 
> Phil
> 
> 
> Artur Malabarba <bruce.connor.am@gmail.com> writes:
> 
> > No problem Phil.
> > Thanks for looking into this.
> > On 20 Nov 2015 7:51 am, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:
> >
> >>
> >> It is my commit after all. I will work on it as soon as I can. Had a nasty
> >> cold for the last few days.
> >>
> >> Phil
> >> ________________________________________
> >> From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org
> >> [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of
> >> Karl Fogel [kfogel@red-bean.com]
> >> Sent: 20 November 2015 01:24
> >> To: Phillip Lord
> >> Cc: Artur Malabarba; emacs-devel
> >> Subject: Re: Apparent regression on the undo command
> >>
> >> phillip.lord@russet.org.uk (Phillip Lord) writes:
> >> >Artur Malabarba <bruce.connor.am@gmail.com> writes:
> >> >> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
> >> >>> I'll try and see if I can automate the problem and
> >> >>> run a bisect.
> >> >>
> >> >> The following works for me. When called on the *scratch* buffer it
> >> >> returns non-nil if the problem occurs.
> >> >>
> >> >> (progn
> >> >>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
> >> >>   (equal (point-min) (point)))
> >> >>
> >> >> That macro simply calls M-< C-k C-n C-n C-k C-/
> >> >
> >> >
> >> >I tried various combinations -- works interactively but fails in batch
> >> >either because *scratch* hasn't been initialized, or undo appears to
> >> >work wrongly.
> >> >
> >> >No worries, it's easy enough to test by hand, and am doing so.
> >>
> >> Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from
> >> commit c210b8b128c.
> >>
> >> Best regards,
> >> -Karl
> >>
> >>
> 

Re: Apparent regression on the undo command

[David Reitter]

Phil,

I tried your fix.  It works for backward-kill-word, but for kill-word (forward), the cursor ends up in the wrong place (after the word, not where it was initially).

- David


> On Nov 21, 2015, at 6:18 AM, Artur Malabarba <bruce.connor.am@gmail.com> wrote:
> 
> I can't speak for the code, but I just tested your fix and looks like it works.
> 
> Thanks Phil.
> 
> 2015-11-21 10:02 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
> 
> I have a possible fix for this now, currently on the
> branch fix/undo-point-in-wrong-place. I waiting for some other feedback
> on my code before I squash and merge it, but if you have the chance it
> would be good to know if it works.
> 
> Phil
> 
> 
> Artur Malabarba <bruce.connor.am@gmail.com> writes:
> 
> > No problem Phil.
> > Thanks for looking into this.
> > On 20 Nov 2015 7:51 am, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:
> >
> >>
> >> It is my commit after all. I will work on it as soon as I can. Had a nasty
> >> cold for the last few days.
> >>
> >> Phil
> >> ________________________________________
> >> From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org
> >> [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of
> >> Karl Fogel [kfogel@red-bean.com]
> >> Sent: 20 November 2015 01:24
> >> To: Phillip Lord
> >> Cc: Artur Malabarba; emacs-devel
> >> Subject: Re: Apparent regression on the undo command
> >>
> >> phillip.lord@russet.org.uk (Phillip Lord) writes:
> >> >Artur Malabarba <bruce.connor.am@gmail.com> writes:
> >> >> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
> >> >>> I'll try and see if I can automate the problem and
> >> >>> run a bisect.
> >> >>
> >> >> The following works for me. When called on the *scratch* buffer it
> >> >> returns non-nil if the problem occurs.
> >> >>
> >> >> (progn
> >> >>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
> >> >>   (equal (point-min) (point)))
> >> >>
> >> >> That macro simply calls M-< C-k C-n C-n C-k C-/
> >> >
> >> >
> >> >I tried various combinations -- works interactively but fails in batch
> >> >either because *scratch* hasn't been initialized, or undo appears to
> >> >work wrongly.
> >> >
> >> >No worries, it's easy enough to test by hand, and am doing so.
> >>
> >> Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from
> >> commit c210b8b128c.
> >>
> >> Best regards,
> >> -Karl
> >>
> >>
> 

Re: Apparent regression on the undo command

[Phillip Lord]

Okay, am working on this now!

David Reitter <david.reitter@gmail.com> writes:

> Phil,
>
> I tried your fix. It works for backward-kill-word, but for kill-word
> (forward), the cursor ends up in the wrong place (after the word, not where it
> was initially).
>
> - David
>
>
>> On Nov 21, 2015, at 6:18 AM, Artur Malabarba <bruce.connor.am@gmail.com> wrote:
>> 
>> I can't speak for the code, but I just tested your fix and looks like it works.
>> 
>> Thanks Phil.
>> 
>> 2015-11-21 10:02 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>> 
>> I have a possible fix for this now, currently on the
>> branch fix/undo-point-in-wrong-place. I waiting for some other feedback
>> on my code before I squash and merge it, but if you have the chance it
>> would be good to know if it works.
>> 
>> Phil
>> 
>> 
>> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> 
>> > No problem Phil.
>> > Thanks for looking into this.
>> > On 20 Nov 2015 7:51 am, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:
>> >
>> >>
>> >> It is my commit after all. I will work on it as soon as I can. Had a nasty
>> >> cold for the last few days.
>> >>
>> >> Phil
>> >> ________________________________________
>> >> From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org
>> >> [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of
>> >> Karl Fogel [kfogel@red-bean.com]
>> >> Sent: 20 November 2015 01:24
>> >> To: Phillip Lord
>> >> Cc: Artur Malabarba; emacs-devel
>> >> Subject: Re: Apparent regression on the undo command
>> >>
>> >> phillip.lord@russet.org.uk (Phillip Lord) writes:
>> >> >Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> >> >> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>> >> >>> I'll try and see if I can automate the problem and
>> >> >>> run a bisect.
>> >> >>
>> >> >> The following works for me. When called on the *scratch* buffer it
>> >> >> returns non-nil if the problem occurs.
>> >> >>
>> >> >> (progn
>> >> >>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
>> >> >>   (equal (point-min) (point)))
>> >> >>
>> >> >> That macro simply calls M-< C-k C-n C-n C-k C-/
>> >> >
>> >> >
>> >> >I tried various combinations -- works interactively but fails in batch
>> >> >either because *scratch* hasn't been initialized, or undo appears to
>> >> >work wrongly.
>> >> >
>> >> >No worries, it's easy enough to test by hand, and am doing so.
>> >>
>> >> Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from
>> >> commit c210b8b128c.
>> >>
>> >> Best regards,
>> >> -Karl
>> >>
>> >>
>> 

bug#21968: Apparent regression on the undo command

[John Wiegley]

>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:

> Okay, am working on this now!

Hi Phil,

I just built emacs-25, but most actions that I take give me errors like the
following:

    Symbol’s function definition is void: undo-auto-amalgamate

Have I omitted to do something?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#21968: Apparent regression on the undo command

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Mon, 14 Dec 2015 12:04:59 -0800
> Cc: David Reitter <david.reitter@gmail.com>, 21968@debbugs.gnu.org
> 
> I just built emacs-25, but most actions that I take give me errors like the
> following:
> 
>     Symbol’s function definition is void: undo-auto-amalgamate
> 
> Have I omitted to do something?

I don't know, but that function is in simple.el.  Did you build in a
clean directory?

bug#21968: Apparent regression on the undo command

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: John Wiegley <jwiegley@gmail.com>
>> Date: Mon, 14 Dec 2015 12:04:59 -0800
>> Cc: David Reitter <david.reitter@gmail.com>, 21968@debbugs.gnu.org
>> 
>> I just built emacs-25, but most actions that I take give me errors like the
>> following:
>> 
>>     Symbol’s function definition is void: undo-auto-amalgamate
>> 
>> Have I omitted to do something?
>
> I don't know, but that function is in simple.el.  Did you build in a
> clean directory?

I'd suspect a clean build here, also. I introduced undo-auto-amalgamate
in eaa1fd6d.

Phil

bug#21968: Apparent regression on the undo command

[John Wiegley]

>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:

>> I don't know, but that function is in simple.el.  Did you build in a
>> clean directory?

> I'd suspect a clean build here, also. I introduced undo-auto-amalgamate in
> eaa1fd6d.

Hmm.. I'm building with Nix, which should by definition mean always having a
clean environment. I'll look into it further.

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#21968: Apparent regression on the undo command

[Phillip Lord]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>>> I don't know, but that function is in simple.el.  Did you build in a
>>> clean directory?
>
>> I'd suspect a clean build here, also. I introduced undo-auto-amalgamate in
>> eaa1fd6d.
>
> Hmm.. I'm building with Nix, which should by definition mean always having a
> clean environment. I'll look into it further.

My guess would be that the src directory has build, but simple.elc was
not. Never used nix, am afraid.

Phil

bug#21968: Apparent regression on the undo command

[John Wiegley]

>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:

> My guess would be that the src directory has build, but simple.elc was not.
> Never used nix, am afraid.

I can confirm after installation that the source file had the function defined
in it, but the compiled version did not. I've changed the Nix build expression
to explicitly remove all .elc files, to force a clean rebuild each time. It's
going much more slowly now, which is heartening.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#21968: Apparent regression on the undo command

[Phillip Lord]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>> My guess would be that the src directory has build, but simple.elc was not.
>> Never used nix, am afraid.
>
> I can confirm after installation that the source file had the function defined
> in it, but the compiled version did not. I've changed the Nix build expression
> to explicitly remove all .elc files, to force a clean rebuild each time. It's
> going much more slowly now, which is heartening.

Well there is a turn up -- someone who is happy that the build is
getting slower!

I think that this issue is probably complete now. Anyone know how to
close it?

Phil

bug#21968: Apparent regression on the undo command

[John Wiegley]

>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:

> I think that this issue is probably complete now. Anyone know how to close
> it?

Closed (by appending "-done" to the bug id in the e-mail addr).

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#21968: Apparent regression on the undo command

[Phillip Lord]

Okay, am working on this now!

David Reitter <david.reitter@gmail.com> writes:

> Phil,
>
> I tried your fix. It works for backward-kill-word, but for kill-word
> (forward), the cursor ends up in the wrong place (after the word, not where it
> was initially).
>
> - David
>
>
>> On Nov 21, 2015, at 6:18 AM, Artur Malabarba <bruce.connor.am@gmail.com> wrote:
>> 
>> I can't speak for the code, but I just tested your fix and looks like it works.
>> 
>> Thanks Phil.
>> 
>> 2015-11-21 10:02 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>> 
>> I have a possible fix for this now, currently on the
>> branch fix/undo-point-in-wrong-place. I waiting for some other feedback
>> on my code before I squash and merge it, but if you have the chance it
>> would be good to know if it works.
>> 
>> Phil
>> 
>> 
>> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> 
>> > No problem Phil.
>> > Thanks for looking into this.
>> > On 20 Nov 2015 7:51 am, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:
>> >
>> >>
>> >> It is my commit after all. I will work on it as soon as I can. Had a nasty
>> >> cold for the last few days.
>> >>
>> >> Phil
>> >> ________________________________________
>> >> From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org
>> >> [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of
>> >> Karl Fogel [kfogel@red-bean.com]
>> >> Sent: 20 November 2015 01:24
>> >> To: Phillip Lord
>> >> Cc: Artur Malabarba; emacs-devel
>> >> Subject: Re: Apparent regression on the undo command
>> >>
>> >> phillip.lord@russet.org.uk (Phillip Lord) writes:
>> >> >Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> >> >> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>> >> >>> I'll try and see if I can automate the problem and
>> >> >>> run a bisect.
>> >> >>
>> >> >> The following works for me. When called on the *scratch* buffer it
>> >> >> returns non-nil if the problem occurs.
>> >> >>
>> >> >> (progn
>> >> >>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
>> >> >>   (equal (point-min) (point)))
>> >> >>
>> >> >> That macro simply calls M-< C-k C-n C-n C-k C-/
>> >> >
>> >> >
>> >> >I tried various combinations -- works interactively but fails in batch
>> >> >either because *scratch* hasn't been initialized, or undo appears to
>> >> >work wrongly.
>> >> >
>> >> >No worries, it's easy enough to test by hand, and am doing so.
>> >>
>> >> Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from
>> >> commit c210b8b128c.
>> >>
>> >> Best regards,
>> >> -Karl
>> >>
>> >>
>> 

Re: Apparent regression on the undo command

[Markus Triska]

Hi Artur,

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> I've been noticing this for days now. Whenever I invoke `undo' (C-/),
> the last change is correctly undone but then sometimes the cursor gets
> moved apparently random places in the buffer.
>
> It took me a couple of days to realise it was moving point to the
> position of my "penultimate" change (the change before the one I just
> undid).

Issue #21722 may be related to this:

   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21722

I began noticing unexpected point positions after undo starting with
Emacs 23.1. I cannot reproduce the regression consistently, and it only
occurs sporadically, but I hope that this helps to get to the root cause
of such problems.

All the best!
Markus