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

61–70 of 84 posts

Re: Text Editor Data Structures: Rethinking Undo

#61

Post by teo_zero »

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 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.

Re: Text Editor Data Structures: Rethinking Undo

#62

Post by afc »

truculent wrote: post #55
thomastjeffery wrote: post #6

Thinking 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.

This resonates with me. I use undo/redo up to a point, but eventually I just reload the file (which I'm saving frequently) or just check it out (from git, mercurial) again.

Re: Text Editor Data Structures: Rethinking Undo

#63

Post by afc »

thomastjeffery wrote: post #6

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

> Something I have wanted to create for a long time (definitely more than 5 years) is a new modal editor. I don't want yet another vi clone: I want something that is defined from the ground up by user configuration.

This is more or less the philosophy of the editor I've been working on (and using ~exclusively) since 2014: https://github.com/alefore/edge/tree/master

Some parts of the UI are still defined in the compiled language (so don't fully fit your philosophy yet), but a big part of the UI comes from the configuration loaded at runtime: every time the editor starts, it interpretes and runs this configuration defining the UI: https://github.com/alefore/edge/blob/master/rc/hooks/start.c...

(This file is not compiled into the editor, but loaded and executed directly at runtime; the format of that file is my editor's extension language/configuration (the equivalent to emacs lisp or vimscript), which just happens to be a garbage collected C-like language.)

Re: Text Editor Data Structures: Rethinking Undo

#64

Post by miniupuchaty »

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

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 argue that this is something that undo should also cover but I don't see much need for that.

I'm not in the insert mode, exiting to normal mode for movement and undo. I'm in the normal mode entering insert mode to write.

Re: Text Editor Data Structures: Rethinking Undo

#65

Post by truculent »

afc wrote: post #62
truculent wrote: post #55

Earlier quoted context omitted.

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.

This resonates with me. I use undo/redo up to a point, but eventually I just reload the file (which I'm saving frequently) or just check it out (from git, mercurial) again.

Right - using undo/redo for quick or ephemeral changes, before solidifying into something (more) permanent feels very similar to me to making a bunch of small commits while working on/exploring something before cleaning them up into semantic chunks with a rebase.

Maybe there’s some implicit idea here like treating a commit as an aggregate of a bunch of atomic actions (i.e what undo/redo act on)

Re: Text Editor Data Structures: Rethinking Undo

#66

Post by eviks »

miniupuchaty wrote: post #64
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

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

Re: Text Editor Data Structures: Rethinking Undo

#67

Post by sureglymop »

truculent wrote: post #55
thomastjeffery wrote: post #6

Thinking 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.

As a music producer who has been working with various DAWs, I've always been super jealous that programmers have git. Not just for version control but also for collaborations.

I always thought, it must be possible because sound is just a list of samples (numbers). Kind of like how a binary executable or assembly code is just a list of values or instructions.

Unfortunately most music software and plugins are proprietary as this industry did not have the same political movements (GNU, F(L)OSS, OSS, etc) that the computer industry had and most professional software has been created for professionals by companies.

It's interesting though because software like Ableton Live has an unlimited undo history but since it is proprietary one can't really look at it.

Re: Text Editor Data Structures: Rethinking Undo

#68

Post by Aerbil313 »

thomastjeffery wrote: post #49
trws wrote: post #23

Earlier quoted context omitted.

Consider my interest piqued. We’ve seen a couple of others in the space, notably Kakoune and Helix. What do you have in mind?

TL;DR: Most (if not all) of the same features, just not as tightly integrated. Every feature is a piece of the puzzle that is your user config. --- Picture Emacs without a default keymap. That's a start. The user builds their own UX from scratch; bringing each feature into their config explicitly . Alternatively, the user just grabs a curated config like Doom Emacs. The difference here is that they can read it: all o…

Compatibility arises from standardization, which only comes after maturity. I don’t expect software industry to mature until another hundred years or so.

Re: Text Editor Data Structures: Rethinking Undo

#69

Post by funcDropShadow »

linsomniac wrote: post #2

I just skimmed it, but it looks like vim really has undo/redo "solved": - Modal editing makes for nice "undo" points, clarifying whether undo should undo "World!" or "!". - "g-" and "g+" eliminate the "orphaned redo". They walk the entire undo/redo tree rather than just the linear undo/redo. - Time travel undo/redo is really handy when you want to go to where you were on the wall-clock. ":earlier 15 minutes" takes yo…

> but it looks like vim really has undo/redo "solved"

Does it support restricting undo/redo to a selection? In Emacs you can select any region of text and just apply the undo history of the selection. That is extremely useful. Imagine working on to functions in the same file. You have are working on g() and realize you want to undo some change on f(), that you did before. Most editors don't support that. In Emacs you can just select the code of f() and press undo (C-_).

Several popular undo extension libraries break this feature.

Re: Text Editor Data Structures: Rethinking Undo

#70

Post by matt-attack »

submeta wrote: post #12
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…

Wow, been using Emacs for decades and didn’t know about „undo in region“. Thanks for sharing!

Emscs undo both both of those reasons is just on another planet than any other editor. Being able to undo your undo (as infinitum) is killer because it just means you can never lose state.

Refional undoing is even more amazing.

Post reply on HN