Can not repeat a sequence of insertion by "." if the smart input assistant is activated #33

Open
kana opened this Issue Mar 16, 2012 · 11 comments

Projects

None yet

4 participants

@kana
Owner
kana commented Mar 16, 2012

For example, a"foo"<Esc>. inserts "foofoo" while the expected result is "foo""foo".

@kana
Owner
kana commented Mar 26, 2012

Related topic: How about undoing? For example:

  1. a"foo<Esc> inserts "foo".
  2. u reverts the last insertion, but the result is "".
  3. One more u revers the text to nothing.

Should the insertion be undone by single u or not?

@kana
Owner
kana commented Mar 28, 2012

It's easy to break undo sequence with <C-g>u in Insert mode, and it's possible to concatenate the last change and a further change with :undojoin.

But it seems not to be possible to make a sequence of insertions as a single unit of undoing. Suppose that user types ifoo<Left>bar<Esc>. Note that:

  • This key sequence is split into two undo blocks: foo and bar.
  • Every key stroke starts a new undo block unless the last inserted character is a printable one.

Even if there is a special key mapping <C-g>j which executes :undojoin, it is not helpfpul. Suppose that user types ifoo<Left><C-g>jbar<Esc>, bar still starts a new undo block! Because bar is interactively typed and <C-g>j and bar is not "executed" as a unit like :undojoin | /something/ delete.

@kana
Owner
kana commented Mar 30, 2012

TODO: Investigate existing implementations deeper. There might be hints for the problems.

@kana
Owner
kana commented Apr 1, 2012

Another solution is to use setline() instead of raw {rhs} of key mappings. But it's not simple, it's not compatible with old versions, and it makes the code base complex. We have to deliberate whether to switch to the solution or not.

@jordwalke

I've seen several plugins that use setline() completely destroy undo/redo behavior in ways that are far worse than the bug reported here. Here, it seems we have extra undos. But the plugins that I've seen using setline() have undo bugs that completely destroy your file. Imagine typing ( and having it automatically insert the ) as expected, but undoing only undoing the first paren, and leaving the second paren regardless of how many times you press undo. this bug seems to related to the granularity of undos, which is nowhere near as bad as bugs related to correctness.

@nbouscal

Could this issue be solved by the use of the vim-repeat plugin? https://github.com/tpope/vim-repeat

@dag
dag commented Jun 14, 2013

From my comment in #63:

Other plugins like vim-autoclose and AutoClose get repeat right but break undo in some cases; specifically I tested adding a newline as part of the change, and it repeated fine, and undo worked, until I undid the last one and I ended up with two empty lines in the buffer, and Vim claiming I was at the oldest change and the [new] buffer was non-modified.

@kana
Owner
kana commented Jul 4, 2013

Both problems might be solved by upgrading Vim to 7.3.1303 or later. Vim 7.3.1303 now supports a way to control breaking the undo history in Insert mode. So it seems that there is nothing to change the code of vim-smartinput.

@nbouscal
nbouscal commented Jul 5, 2013

I've just upgraded to 7.3.1308 and both the undo problem and the repeat problem seem to still be there.

@kana
Owner
kana commented Jul 5, 2013

I tried Vim 7.3.1303 and I noticed that I misunderstood the patch. While evaluating an expression to = doesn't break undo history by default, the problem happens when the result is being inserted. So that nothing has changed for vim-smartinput.

@dag
dag commented Jul 5, 2013

Isn't the problem that the "changes" as Vim sees them are already too broken up, and what we want is rather to make it one atomic change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment