Broken undo?

99 views
Skip to first unread message

Israel Chauca F.

unread,
May 13, 2010, 3:38:50 AM5/13/10
to vim...@googlegroups.com
Hi there,

I found the following, open vim and do the following:

- Insert 1 and exit insert mode.
- Append 2 and then <C-R>=setline('.', '123')<CR> to add one char to the right of the cursor.
- Without leaving insert mode, type other <CR> and the number 4, now exit insert mode.
- Press u.

I should expect to have just the number 1 in the window, but I'm left with two lines:

1
43

If I undo again, I get the original empty window.

If I start in the second step, I can't undo to the empty window, I'm left with two lines but I can exit vim as if the buffer was in its original state.

Is that the expected behaviour or there is something wrong? why does the setline() call + <CR> affects the first edit?

Thanks!
Israel




--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Tony Mechelynck

unread,
May 13, 2010, 5:14:07 AM5/13/10
to vim...@googlegroups.com, Israel Chauca F.
On 13/05/10 09:38, Israel Chauca F. wrote:
> Hi there,
>
> I found the following, open vim and do the following:
>
> - Insert 1 and exit insert mode.
> - Append 2 and then<C-R>=setline('.', '123')<CR> to add one char to the right of the cursor.
> - Without leaving insert mode, type other<CR> and the number 4, now exit insert mode.
> - Press u.
>
> I should expect to have just the number 1 in the window, but I'm left with two lines:
>
> 1
> 43
>
> If I undo again, I get the original empty window.
>
> If I start in the second step, I can't undo to the empty window, I'm left with two lines but I can exit vim as if the buffer was in its original state.
>
> Is that the expected behaviour or there is something wrong? why does the setline() call +<CR> affects the first edit?
>
> Thanks!
> Israel
>
>
>
>

In 'compatible' mode (including, by default, when you start Vim with no
vimrc, or with the -u command-line switch in order to use a nonstandard
vimrc), repeatedly hitting u alternates between the two latest states of
the buffer (this is vi-compatible "undoable undo").

In 'nocompatible' mode, including when Vim has found a .vimrc or a
_vimrc, repeatedly hitting u goes progressively backwards in time, up to
'undolevels' times. In that case, CTRL-R (in Normal mode) redoes what
had been undone.

See
:help 'undolevels'
:help undo-two-ways


Best regards,
Tony.
--
Cold, adj.:
When the politicians walk around with their hands in their own
pockets.

Christian Brabandt

unread,
May 13, 2010, 5:49:47 AM5/13/10
to vim...@googlegroups.com
Hi Israel!

On Do, 13 Mai 2010, Israel Chauca F. wrote:

> Hi there,
>
> I found the following, open vim and do the following:
>
> - Insert 1 and exit insert mode.
> - Append 2 and then <C-R>=setline('.', '123')<CR> to add one char to the right of the cursor.
> - Without leaving insert mode, type other <CR> and the number 4, now exit insert mode.
> - Press u.
>
> I should expect to have just the number 1 in the window, but I'm left with two lines:
>
> 1
> 43

I can reproduce it. That looks like a bug to me

> If I undo again, I get the original empty window.
>
> If I start in the second step, I can't undo to the empty window, I'm left with two lines but I can exit vim as if the buffer was in its original state.
>

I can't reproduce that.

> Is that the expected behaviour or there is something wrong? why does the setline() call + <CR> affects the first edit?

It shouldn't I guess. Report it to Bram

regards,
Christian

Bram Moolenaar

unread,
May 13, 2010, 7:12:53 AM5/13/10
to Israel Chauca F., vim...@googlegroups.com

Israel Chauca wrote:

> I found the following, open vim and do the following:
>
> - Insert 1 and exit insert mode.
> - Append 2 and then <C-R>=setline('.', '123')<CR> to add one char to
> the right of the cursor.
> - Without leaving insert mode, type other <CR> and the number 4, now
> exit insert mode.
> - Press u.
>
> I should expect to have just the number 1 in the window, but I'm left
> with two lines:
>
> 1
> 43

That indeed looks like a bug.

> If I undo again, I get the original empty window.
>
> If I start in the second step, I can't undo to the empty window, I'm
> left with two lines but I can exit vim as if the buffer was in its
> original state.

I don't see this problem.

> Is that the expected behaviour or there is something wrong? why does
> the setline() call + <CR> affects the first edit?

A whole insert should be one undo step. But when you invoke setline()
this is messed up. Evaluating the expression was not supposed the side
effect of changing the text.

--
"You know, it's at times like this when I'm trapped in a Vogon airlock with
a man from Betelgeuse and about to die of asphyxiation in deep space that I
really wish I'd listened to what my mother told me when I was young!"
"Why, what did she tell you?"
"I don't know, I didn't listen!"
-- Arthur Dent and Ford Prefect in Douglas Adams'
"The Hitchhiker's Guide to the Galaxy"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Israel Chauca F.

unread,
May 13, 2010, 3:31:49 PM5/13/10
to Bram Moolenaar, vim...@googlegroups.com
On May 13, 2010, at 6:12 AM, Bram Moolenaar wrote:
>
>
> Israel Chauca wrote:
>
>> I found the following, open vim and do the following:
>>
>> - Insert 1 and exit insert mode.
>> - Append 2 and then <C-R>=setline('.', '123')<CR> to add one char to
>> the right of the cursor.
>> - Without leaving insert mode, type other <CR> and the number 4, now
>> exit insert mode.
>> - Press u.
>>
>> I should expect to have just the number 1 in the window, but I'm left
>> with two lines:
>>
>> 1
>> 43
>
> That indeed looks like a bug.

Good to know. Should I write a ticket for this bug somewhere or do something else?

>
>> If I undo again, I get the original empty window.
>>
>> If I start in the second step, I can't undo to the empty window, I'm
>> left with two lines but I can exit vim as if the buffer was in its
>> original state.
>
> I don't see this problem.

I can reproduce it in the default vim for MacOS X 10.6 and MacVim, but neither of them are the latest version, when I can compile vim in my Mac I'll try again.

Thanks!
Israel

Bram Moolenaar

unread,
May 13, 2010, 4:56:38 PM5/13/10
to Israel Chauca F., vim...@googlegroups.com

Israel Chauca wrote:


> >> I found the following, open vim and do the following:
> >>
> >> - Insert 1 and exit insert mode.
> >> - Append 2 and then <C-R>=setline('.', '123')<CR> to add one char to
> >> the right of the cursor.
> >> - Without leaving insert mode, type other <CR> and the number 4, now
> >> exit insert mode.
> >> - Press u.
> >>
> >> I should expect to have just the number 1 in the window, but I'm left
> >> with two lines:
> >>
> >> 1
> >> 43
> >
> > That indeed looks like a bug.
>
> Good to know. Should I write a ticket for this bug somewhere or do
> something else?

No need. Storing bugs in a dusty database won't help getting them
solved.

> >> If I undo again, I get the original empty window.
> >>
> >> If I start in the second step, I can't undo to the empty window, I'm
> >> left with two lines but I can exit vim as if the buffer was in its
> >> original state.
> >
> > I don't see this problem.
>
> I can reproduce it in the default vim for MacOS X 10.6 and MacVim, but
> neither of them are the latest version, when I can compile vim in my
> Mac I'll try again.

Perhaps you need to explain more cleary what you do exactly.

--
To define recursion, we must first define recursion.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Israel Chauca F.

unread,
May 13, 2010, 5:43:49 PM5/13/10
to Bram Moolenaar, vim...@googlegroups.com
On May 13, 2010, at 3:56 PM, Bram Moolenaar wrote:
>
>
>>> That indeed looks like a bug.
>>
>> Good to know. Should I write a ticket for this bug somewhere or do
>> something else?
>
> No need. Storing bugs in a dusty database won't help getting them
> solved.

Noted.

>>>> If I undo again, I get the original empty window.
>>>>
>>>> If I start in the second step, I can't undo to the empty window, I'm
>>>> left with two lines but I can exit vim as if the buffer was in its
>>>> original state.
>>>
>>> I don't see this problem.
>>
>> I can reproduce it in the default vim for MacOS X 10.6 and MacVim, but
>> neither of them are the latest version, when I can compile vim in my
>> Mac I'll try again.
>
> Perhaps you need to explain more cleary what you do exactly.

The next steps are are just one insert:
1. Insert 1.
2. Now <C-R>=setline('.','12')<CR>
3. Insert <CR>
4. Exit insert mode and undo (u).

The buffer should be empty but it has two lines, the first one is empty and the second one has the number 2 in it. Since the buffer isn't empty, I should get E37 when I :quit, instead vim exits without any message.

Let's see if that works.

Thanks,
Israel

Bram Moolenaar

unread,
May 14, 2010, 5:44:40 AM5/14/10
to Israel Chauca F., vim...@googlegroups.com
I see it. It's the same problem as the first one in a different form.

--
hundred-and-one symptoms of being an internet addict:
34. You laugh at people with 14400 baud modems.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Bram Moolenaar

unread,
Apr 21, 2013, 7:07:23 AM4/21/13
to Mime Čuvalo, vim...@googlegroups.com, Israel Chauca F.

Israel Chauca wrote:

> Hello,
> I see this thread is a bit old (and that no bug was filed :P) but was
> wondering:
> - did this ever get resolved?
> - or, is there a workaround?
>
> For me the issue arises in usage of the delimitMate plugin (related
> bug: https://github.com/Raimondi/delimitMate/issues/114 )

The issue is still in the todo list. That list is rather long...

--
hundred-and-one symptoms of being an internet addict:
200. You really believe in the concept of a "paperless" office.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///

Christian Brabandt

unread,
Apr 21, 2013, 8:16:06 AM4/21/13
to vim...@googlegroups.com, Bram Moolenaar
Hi Mime!

On Sa, 20 Apr 2013, Mime Čuvalo wrote:

> Hello,
> I see this thread is a bit old (and that no bug was filed :P) but was wondering:
> - did this ever get resolved?
> - or, is there a workaround?
>
> For me the issue arises in usage of the delimitMate plugin (related bug: https://github.com/Raimondi/delimitMate/issues/114 )

Can you check, if this patch fixes it for you?
https://groups.google.com/d/msg/vim_use/Rw637BtyIWs/WSWPdp4jW2oJ

Mit freundlichen Grüßen
Christian
--
Wenn der Kernel keinen Treiber für das ATAPI-CDROM hat,
wie soll er dann dafür eine SCSI-Emulation machen?
Merke: erst denken, dann posten.
-- Felix von Leitner
Reply all
Reply to author
Forward
0 new messages