Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Text Editor Data Structures: Rethinking Undo

cdacamar.github.io

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Text Editor Data Structures: Rethinking Undo

#71

Post by Someone »

genter wrote: post #53
bsder wrote: post #40

Earlier quoted context omitted.

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.

Not the first Macs, the work-in-progress Lisas they used for user research https://www.folklore.org/StoryView.py?story=Do_It.txt:

“Starting in the summer of 1981, Larry organized a series of user tests of the nascent Lisa software, recruiting friends and family to try out the software for the first time, while being observed by the Apple designers who recorded their reaction.

[…]

Finally, the team noticed one user that was particularly flummoxed by the dialog box, who even seemed to be getting a bit angry. The moderator interrupted the test and asked him what the problem was. He replied, "I'm not a dolt, why is the software calling me a dolt?"

It turns out he wasn't noticing the space between the 'o' and the 'I' in 'Do It'; in the sans-serif system font we were using, a capital 'I' looked very much like a lower case 'l', so he was reading 'Do It' as 'Dolt' and was therefore kind of offended.

After a bit of consideration, we switched the positive confirmation button label to 'OK' (which was initially avoided, because we thought it was too colloquial), and from that point on people seemed to have fewer problems.”

Re: Text Editor Data Structures: Rethinking Undo

#72

Post by thomastjeffery »

teo_zero wrote: post #61
thomastjeffery wrote: post #43

Earlier quoted context omitted.

The coolest feature of Vim is its macros. They bring the entire UX into one cohesive feature. The keymap has meaning, because every key symbol is a character, and a macro is just a string. You can paste them, edit them, copy them, then play them back; all without ever leaving Vim's primary UX. Macros are stories written, not in vimscript, but in the language of Vim itself . Macros are also the reason I don't use Vim…

> I tried remapping the keys. Not only was that impossible (circular dependencies) I don't get this. To swap x and y is easy: noremap x y noremap y x Of course you can't do it with map, that's why noremap exists.

Believe me, I have tried. It's been a while, or I would tell you precisely what went wrong. Suffice it to say, I did not give up easily.

Even if it did work, I wouldn't have the conceptual map that Vim's UX is made of. Without that, it's just not going to be a positive experience.

Re: Text Editor Data Structures: Rethinking Undo

#73

Post by rodlette »

globular-toast wrote: post #4

Emacs undo-tree does everything I need. Emacs also supports undo in region which most editors don't seem to support and wasn't covered by the article. I actually used regular Emacs undo for years which lets you get everywhere in the tree with a kind of tree traversal but you won't know where you are. I resisted undo-tree for ages but it's definitely worth it as it stays out of the way until the occasion you might nee…

vundo is a simpler implementation: it reuses Emacs's built-in undo/redo and just implements the tree visualisation part.

undo-tree is a reimplementation of Emacs's undo/redo, that supports a tree visualization.

* undo-tree LOC: 4700. https://gitlab.com/tsc25/undo-tree/-/blob/master/undo-tree.e...

* vundo LOC: 1350. https://github.com/casouri/vundo/blob/master/vundo.el

Re: Text Editor Data Structures: Rethinking Undo

#74

Post by globular-toast »

rodlette wrote: post #73
globular-toast wrote: post #4

Emacs undo-tree does everything I need. Emacs also supports undo in region which most editors don't seem to support and wasn't covered by the article. I actually used regular Emacs undo for years which lets you get everywhere in the tree with a kind of tree traversal but you won't know where you are. I resisted undo-tree for ages but it's definitely worth it as it stays out of the way until the occasion you might nee…

vundo is a simpler implementation: it reuses Emacs's built-in undo/redo and just implements the tree visualisation part. undo-tree is a reimplementation of Emacs's undo/redo, that supports a tree visualization. * undo-tree LOC: 4700. https://gitlab.com/tsc25/undo-tree/-/blob/master/undo-tree.e... * vundo LOC: 1350. https://github.com/casouri/vundo/blob/master/vundo.el

Nice, I will try vundo!

Re: Text Editor Data Structures: Rethinking Undo

#75

Post by phs2501 »

afc wrote: post #44

In 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…

This is how traditional Emacs undo is implemented as well. I like it but it seems to be not the norm; it does take a little bit to get used to. (There's plenty of packages to transform Emacs undo into something more like a tree structure, though I don't personally use them because I'm used to the above behavior.)

Re: Text Editor Data Structures: Rethinking Undo

#76

Post by alpaca128 »

thomastjeffery wrote: post #43
alpaca128 wrote: post #35

Earlier quoted context omitted.

I am currently working on an editor. Definitely interesting to try different ideas just to find out why certain things in Vim are that way. Also the "." key is more complicated than I expected, the exact start of an edit operation depends on the behaviour of certain default keybindings. It just works so smoothly I had never thought much about it before. > Maybe one of these days I will get far enough past the ADHD wa…

The coolest feature of Vim is its macros. They bring the entire UX into one cohesive feature. The keymap has meaning, because every key symbol is a character, and a macro is just a string. You can paste them, edit them, copy them, then play them back; all without ever leaving Vim's primary UX. Macros are stories written, not in vimscript, but in the language of Vim itself . Macros are also the reason I don't use Vim…

I had different reasons but I only hardcoded a few basic keybindings like Escape. Everything else is customizable, but still limited to the three modes (it's just a good combination). Defining explicit keybindings for every symbol on the keyboard turned out to be the cleanest way to fix bugs in the input handler, special behaviour just for insert mode isn't worth it.

> I tried remapping the keys. Not only was that impossible (circular dependencies)

I wonder if that could be remapped in the code itself? From a quick look they seem to be defined in ops.c and vim.h, but I'm not very familiar with the codebase.

Re: Text Editor Data Structures: Rethinking Undo

#77

Post by fwip »

eviks wrote: post #66
miniupuchaty wrote: post #64

Earlier quoted context omitted.

I don't have this problem in practise. It's not "break flow to switch modes" for me. I don't type this way. There's always as much movement as there's typing, especially while programming. Even when writing prose I exit the insert mode each time I think of what to write next making this always a good "undo point". If I make a typo while in the insert mode I just remove last character or last word. I guess you could a…

While the inferiority of your workflow doesn't matter to you, it's still a point against undo being "solved" by vim

What problem does a magical "does what I mean" undo solve that pressing ^W or ^H doesn't? At a minimum, your "superior workflow" is "ui" or "^Ou", both of which are more keystrokes and require your editor to read your mind.

Re: Text Editor Data Structures: Rethinking Undo

#78

Post by linsomniac »

eviks wrote: post #56
linsomniac wrote: post #47

Earlier quoted context omitted.

>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

There are alternatives to "undo", which are probably better suited to "undo last word" without making "what will undo undo" more mentally complicated. Having undo reverse the last edit, whether that's a word or a few words or adding an argument definition to a function, or adding an "if" block -- makes it very easy to keep in your head. "I want to undo that last thing I did".

The alternatives are:

    - Control-W (delete the last word, stay in insert mode)
    - "W" to move back a word (or "B" to move back a big word).  So: BC
There's apparently also a recipe for setting up vim to insert undo points whenever you hit space, so you could also enable that for the files you want to do that on.

Re: Text Editor Data Structures: Rethinking Undo

#79

Post by eviks »

linsomniac wrote: post #78
eviks wrote: post #56

Earlier quoted context omitted.

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

There are alternatives to "undo", which are probably better suited to "undo last word" without making "what will undo undo" more mentally complicated. Having undo reverse the last edit, whether that's a word or a few words or adding an argument definition to a function, or adding an "if" block -- makes it very easy to keep in your head. "I want to undo that last thing I did". The alternatives are: - Control-W (delete…

understanding of what that "last thing I did" isn't session specific, like "adding an if block and a long comment describing what that block does" is semantically two last things I did, the fact that they're happening within a single insert session doesn't help. And I don't really need too keep it in my head, a solved undo would make it visually obvious to free my head

The alternatives you suggest are bad: 1. This is no undo, so then it's not part of redo

2. Why would I ever want 3 undo points if I indent my comment a bit by 3 spaces?

Re: Text Editor Data Structures: Rethinking Undo

#80

Post by eviks »

fwip wrote: post #77
eviks wrote: post #66

Earlier quoted context omitted.

While the inferiority of your workflow doesn't matter to you, it's still a point against undo being "solved" by vim

What problem does a magical "does what I mean" undo solve that pressing ^W or ^H doesn't? At a minimum, your "superior workflow" is " ui" or "^Ou", both of which are more keystrokes and require your editor to read your mind.

Or my superior workflow is Alt-u or hold U, which is a single shortcut/keystroke, so you lose there as well

The other issue with your attempt at solving undo without undo is that the deletion doesn't become part of redo, also a single word with a typo could be in the middle of a paragraph where you navigated with a trackpad, while ^W would delete near the current cursor position

You don't need magic to fix the ubersimplicity of current defaults, just a bit of openness

Post reply on HN