On Tue, Dec 9, 2008 at 2:48 PM, Krzysiek Goj <[EMAIL PROTECTED]> wrote: > > Hi! > > I've read discussion under issue 210, but when replying to it I felt I > was drifting off from original problem towards sorting off all the > World's undo-redo problems, so I'll start a more general discussion > here. > > IMHO, we should have one general (keymap-independent) approach which > is powerful enough to emulate both vim's and emacs'es behaviour being > customizable at the same time.
Yes! > The approach I'd love to see is to have compound actions in undo-redo > history (let's call them transactions). > User entering insert mode in vim would start a transaction. Leaving > insert mode ends a transaction, so now single 'u' undoes all the > insertion and '.' inserts the same text once again. > > Users would be able to make use of transactions in their own > functions, so for example one emulating vim's surround script (http:// > www.vim.org/scripts/script.php?script_id=1697) would easily make all > those inserting nested parens undoable (and dot-repeatable) by > wrapping some functions in such a transaction. > > We should be able to nest transactions, eg. it would be cool if we > could easily write keyboard macros that transactions. Part of such a > macro would be an user-defined action that is atomic on it's own, etc. > > It seems to me that a natural way of building such a transaction is > using a stack (it would be similar to building OpenGL's transformation > using matrix stack and glPush/glPop). > > Implementation idea: > We have a stack of histories. All actions would operate on topmost > history. Keymap would be allowed to push an empty history on top of > stack or pop from top of stack. Popping non-empty history means > inserting compound action (made of old top's actions) to new stack > top. Thus, everything between historyPush and historyPop is a > transaction and transactions can be nested and composed in fancy ways. > > Cross-cutting concerns: vim's dot-command and undo tree. > > What do you think about it? Sounds really good, we might just start working out the details. I have to mention however that at the moment we store updates individually and revert them as needed. It might make sense to do this differently: since we use a fingertree for the buffer, we can just keep (a pointer to) the whole buffer states we might want to undo to. This might simplify the implementation. Cheers, JP. --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list [email protected] http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
