2014-04-06 23:09 GMT+04:00 Bram Moolenaar <[email protected]>: > > Ben Fritz wrote: > > > On Sunday, April 6, 2014 6:42:35 AM UTC-5, Bram Moolenaar wrote: > > > > > The problem is that there will not be a standard way how to apply those > > > two changes. If it's just two inserts after another it would be > > > possible, but in general the cursor would have moved somewhere else and > > > perhaps indent depends on the indent of another line. > > > > > > Most likely the solution lies in repeating what the plugin does by > > > invoking the plugin again. Instead of trying to record and replay what > > > the plugin ended up doing. So the redo buffer would contain whatever > > > triggered the plugin, and redo would trigger the plugin again. > > > > > > How do these kind of plugins get triggered anyway? Insert mode > mapping? > > > Would be good to start with a relevant example. > > > > At its heart, this kind of plugin is an insert-mode mapping, where > > when you press ( you get () instead, with the cursor in between. > > > > To get it to work with the '.' operator, it also needs mappings for > > <Esc> and some other commands so it can invoke repeat.vim. > > > > But for undo/redo, there was not any known solution last I knew. I > > guess Justin may have found something as he posted earlier. I haven't > > seen it working in practice yet, I will probably try it out later this > > week. The difficulty is that EVERY cursor movement in insert-mode will > > break the undo sequence and there is no way around it. It would be > > nice to have some sort of movement command within a line that would > > not break the undo sequence, or an explicit command to join two > > arbitrary edits, or a command from normal mode that would start insert > > mode and join the resulting insert to the last undo in the chain. > > Adding these commands will make life more complicated. I think the > solution would be to have a different kind of map, which indicates that > undo is not to be split, and what the map results in should not be added > to the redo buffer. Instead, what triggered the map is to be added to > the redo buffer. So that redo-ing it will trigger the map again. > > This won't be easy, it probably requires adding markers in the typeahead > buffer and redo buffer, but it's certainly better than adding a bunch of > strange commands to move around without splitting undo/redo. > > Actually, vim already supports "complicated" undo/redo: say, if file was changed externally, Vim asks if it should reload it. If user answers "yes", vim loads file, compare it with buffer contents, and all of changes are written as just single action.
Here, when user wants to join several actions, we need for the same, plus repeating it with a dot. About repeating with a dot: repeat.vim is not an option here: it is useful when I have exact mapping to be repeated. But here I must repeat all that user typed before plugin "pressed" <Left> key, and after it too, so, I have to remap all the thousand ways of quitting insert mode, and then give to repeat.vim all that user just typed. -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
