Conversation

One reason we don't have more interesting, quality structured text editors: it's *really* hard to implement table-stakes editing operations well, particularly on web. In this video, I attempt to arrow up/down and shift+up/down to select inter-line in 8 outliners. Very yikes.
Embedded video
1:45
14K views
21
29
245
Replying to
This sounds so nit-picky and trivial, but I think the difficulty of getting basic editing ops done well in simple outline UX illustrates just how painful it is to make a structured text editor nice enough to live in. There'd be a lot of value in finding a good abstraction here.
13
1
88
Incidentally, the Cocoa text system is a remarkably good text editing abstraction, and it's accreted improvements over three decades since its introduction in NeXTStep. It does a great job of supporting simultaneous use of multiple levels of abstraction.
3
4
40
This Tweet was deleted by the Tweet author. Learn more
Replying to
I wonder if this is mostly due to how much simpler it is to make a block-based editor vs a text-based editor. I did a bit of exploration there for my own native iOS editor. Going block-based means you lose all inter-block interactions, but much more extensible
Quote Tweet
I’m working on a side project similar to Bear/Dropbox Paper/Notion/Craft where you can have a document with text/todos/lists/images all together. I’m curious how you would implement this on iOS?
Show this thread
1
Show replies
Replying to
Interesting! I've found that up/down navigation between blocks in Roam has a noticeable delay (hundreds of ms), and checking again now, that's only when navigating from mid-line. Does getting it right within a JavaScript framework involve that much extra lifting?