| 05:22 |
verisimilitude |
So, would anyone care to read my recent thoughts on how to structure an undo system? |
| |
~ 1 hours 33 minutes ~ |
| 06:56 |
verisimilitude |
I see there's a lot of interest, so I'll explain. |
| 06:57 |
verisimilitude |
The original context was the undo system of an Elision editor. An editor would use a doubly-linked-list of Elision codes, with one node per word. The undo system would ideally be a doubly-linked-list of command history. |
| 06:57 |
verisimilitude |
I realized yesterday that it would be simple to embed most of the history in the document itself, rather than in the command history. So, changing a word would push to a doubly-linked-list of words in the node. The command history is then just ``push at so-and-so node''. An undo would know to then ``pop at so-and-so node'' and isn't that neat? |
| 06:57 |
verisimilitude |
I never considered this for the MMC, since I figured such embedding would make normal operation too inconvenient, but it's very little for this editor, and may be worth reconsidering for the MMC. |
| 06:58 |
verisimilitude |
So, the basic idea is having a measly command history, and finding a way to more naturally shove most of the history into the primary data structure of the program. |
| |
~ 7 hours 3 minutes ~ |
| 14:01 |
asciilifeform |
verisimilitude: this is a Right Thing (and oughta be systemwide) but tricky to implement for general case. |