driusan
commented
8 years ago If I'm reading that right, that system is designed to minimize network bandwidth/conflicts for multiple users editing a file at the same time (ie. Google Docs like editors), so I'm not sure what the benefit would be for a single-user offline application.
I think the easiest thing to do would be to just have an Undo pointer in the demodel.CharBuffer which points to the last CharBuffer and gets maintained after every delete operation or when exiting insert mode. It would be even easier to implement than a scratch file and provide multi-level undo functionality. Theoretically, the memory could grow unbounded if you're doing a lot of edits but I think practically with the size of your average source code file (probably 5-100k), the fact that you don't do too many edits before going to a different file, and source code is read more often than it's edited, I think the memory size of the image which is rendered into the viewport would probably dwarf the size of an in-memory Undo-linked-list, on average.
I just haven't gotten around to trying it to see if my reasoning is accurate or not.
If you make a mistake with delete mode and notice it right away, you can also use p as a very primitive single-level undo, but obviously that's not really adequate.
probably the most painful thing about learning a new editor is making a destructive mistake. Also, leaving focus on the editor while a cat is near the keyboard.
There's a number of approaches, but I'd love to use something compatible with Operational transformation. I know my way around CRDTs, but I don't yet know how to implement anything on that wiki page.
Regardless, each buffer operation will need to be wrapped so a handler can be triggered. Initial implementation could just be a scratch file and a single operation undo (like it's 1995!).