I'm not sure if it was recorded, but I think Don Knuth's Christmas lecture last week was on a related topic. It's a follow-up to his 2018 lecture:
Text Editor Data Structures: Rethinking Undo
51–60 of 84 posts
Re: Text Editor Data Structures: Rethinking Undo
#52[dead]
Re: Text Editor Data Structures: Rethinking Undo
#53Maya's C++ API was what taught me the most about the importance of proper do/undo functionality. As soon as you start to modify the DAG, you really must ensure that the undo operation leaves everything (be it meshes or shaders or curves, whatever) as it was before your custom object got inserted into the DAG. Else your plugin is worthless. See the doIt/undoIt methods in https://help.autodesk.com/view/MAYAUL/2022/ENU/…
Man, fonts sometimes really matter. I've been pondering about calling your developers nasty names and what a dolt method is actually doing ... Until I realized that they were DO-IT, UNDO-IT.
Bit of trivia:
The first Macs (or maybe it was the Lisa) had DO IT instead of OK. The people in the focus groups testing it got annoyed that they were being called dolts.
Re: Text Editor Data Structures: Rethinking Undo
#54Thinking about undo/redo is a great place to start thinking about your text editor's underlying data structure. I went down this rabbit hole a while back. I had to really dig[1]: it's been 5 years... --- Data structures aren't the only interesting rabbit-hole, though. UI/UX doesn't get nearly as much attention as it deserves. There are really only two that I am aware of: Notepad and Vim. Vim's modal editing results i…
> Vim's modal editing results in the user explicitly defining undo/redo points. ? How? Does switching to normal mode create an undo/redo point? Someone asked me if the granularity of Vim's undo/redo could be increased (i.e., more frequent undo/redo points). In what they demonstrated, Vim's granularity seemed less than other applications (i.e., undo/redo acted on relatively large chunks of input); in some brief resear…
Well, in Vim, "switching to normal mode" can be thought of as "ending an insert command" instead of "switching modes", which makes sense as soon as you realize that normal mode is, well, normal.
So when you press "o", I don't think "switch to insert mode". I think "insert a line with the following text:", which can then be undone with u, repeated with ., or whatever else you want.
At least that's my mental model of Vim, I don't know which is closer to reality.
Re: Text Editor Data Structures: Rethinking Undo
#55Thinking about undo/redo is a great place to start thinking about your text editor's underlying data structure. I went down this rabbit hole a while back. I had to really dig[1]: it's been 5 years... --- Data structures aren't the only interesting rabbit-hole, though. UI/UX doesn't get nearly as much attention as it deserves. There are really only two that I am aware of: Notepad and Vim. Vim's modal editing results i…
As what point does a fully featured undo/redo system start to look like git (/VCS of choice)?
Once you add deliberate checkpoints and the tree structure from the article, it feels like you’re more than halfway there.
Re: Text Editor Data Structures: Rethinking Undo
#56Earlier quoted context omitted.
Far from solved Modal editing isn't enough if you type whole sentences/paragraphs of text within a single insert session Also undo in selection is required to "solve" it, as well as semantic points besides "last 15 minutes" (like "last saved session" or "last time you quit the editor") Also UI with a diff is sometimes better than having to undo/redo to see changes
>Modal editing isn't enough if you type whole sentences/paragraphs of text within a single insert session Why not? Honest question.
Because it's too coarse: undoing the whole paragraph instead of just the last word with a typo is too much, so you'd have to be always aware of this limitation and break flow to switch modes for no other reason than to insert "undo points", and these are unnecessary mental bookkeeping chores
Re: Text Editor Data Structures: Rethinking Undo
#57In my text editor ( https://github.com/alefore/edge ) I keep the undo/redo history always linear, which I find works pretty well. So suppose the user does the following operations: • Insert "Hello" • Insert " world!" • Undo once. • Insert ", Cameron!" At this point, undo operations would gradually transform the buffer thus: "Hello, Cameron!" => "Hello" => "Hello world!" => "Hello" => "". Obviously, one can redo at an…
Interesting, none of the editors I just tested (notepad / visual studio / sublime / github) works like this.
I think of undo/redo as "time traveling", going back to where I was one / two / several steps bevor. The mental model of your implementation is more akin of actually "doing" the undo. Like if you undo insert " world!", you create an action that deletes " world!". The timeline still goes forward, but now has a delete action.
Re: Text Editor Data Structures: Rethinking Undo
#58Thinking about undo/redo is a great place to start thinking about your text editor's underlying data structure. I went down this rabbit hole a while back. I had to really dig[1]: it's been 5 years... --- Data structures aren't the only interesting rabbit-hole, though. UI/UX doesn't get nearly as much attention as it deserves. There are really only two that I am aware of: Notepad and Vim. Vim's modal editing results i…
> Maybe one of these days I will get far enough past the ADHD wall to make it happen...
I have that hope for literally hundreds of things... but I know I will never actually get to do any of those things. I can think of any one of them right now and be unable to even try. I hate this existence.
Re: Text Editor Data Structures: Rethinking Undo
#59The idea of an undo “graph” in memory is something I’ve implemented, and in C++ even, so it was fun to read the article. Couldn’t agree more — once you’ve had it, going back to the linear, often truncated thing most application implement is a little sad.
In my case when state A transitioned to B, was undone and further changes made to get state C I would retain the XOR of the changed memory of the A->B transition as run length encoded bytes B’ and similarly C’ so it was lightweight and extremely fast to undo and redo (the latter being exactly the same as the former but applied to A rather than B, since that’s how XOR works). Cool stuff.