It’s a good example of what else you can do with TextKit2, beyond plain text rendering. Here, I can draw text layout fragments in a core graphics context and use typographic information to also render markdown specific graphics in the background or foreground such as markdown tables. One day I’d love to experiment with a markdown centric spread sheet app.
At the time there was so little online info that I had to figure out everything on my own (and no chatbots didn’t have a clue about TextKit2), but STTextView was a great reference. Overall his open source work was very much appreciated. (I should probably say as much in the read me.)
That experiment was also a ton of work that ultimately didn’t go anywhere. Most people would rather just use a relatively subpar embedded browser (i.e. web view).
Oh also I’d like to add to the above, the TextKit2 API is way more freeform than people think. You could probably implement your own web browser upon it with optimized line by line text rendering (which isn’t that bad). One thing I always wanted to experiment with is rendering markdown content with horizontally scrollable text fragments for table rows and certain fenced code blocks. Super cool and practical idea for native markdown text rendering. Moreover, in some ways it seems pretty easy to do in TextKit2 since you get very fine grained control over text layout fragment rendering.
> TextKit2 is implemented to be used by UITextView
This is the key insight that makes TextKit2 workable. I personally would not attempt to build an alternative to UITextView on TextKit (1 or 2). Instead, TextKit2 is all about very sensible intervention points for customizing UITextView (eg, Markdown-style parsing, typography, interactions, layout).
I recently rebuilt Minimal’s editor with TextKit2 (see minimal.app/#beta to experience it), and found Kryzanowskim’s deep dives very fruitful. He explores the edges of the API, so his writing helped me identify a nice bounds of safe-space to work in, and helped clarify what areas are too complex to safely build custom functionality within. (So thank you, author!)
I would not dismiss TextKit2; it is an incredible improvement over TextKit1. It remains a complicated and challenging field.
> I personally would not attempt to build an alternative to UITextView on TextKit (1 or 2)
sure. If only UITextView/NSTextView did not have bugs impossible to workaround otherwise. TextKit 2 support in UITextView/NSTextView was really bad. improved over time. and still remain buggy. The UITextView focus limits the use of TextKit 2 architecture significantly.
I have to wonder if the scrollbar problem is inescapable, given the shape of the problem.
Flutter has dealt with similar issues, perhaps by virtue of more eyeballs / being slightly older, there are solutions. SuperSliverList in particular completely erased the jumpy-jank that happened when estimates changed to concrete values.
as long as we deal with estimated values, it is inescapable. the best we can do is tune the estimate calculations and tweak heuristics. that's my understanding of the problem, but I'd love to hear from other experience
https://github.com/SuperSwiftMarkup/SuperSwiftMarkdownProtot...
It’s a good example of what else you can do with TextKit2, beyond plain text rendering. Here, I can draw text layout fragments in a core graphics context and use typographic information to also render markdown specific graphics in the background or foreground such as markdown tables. One day I’d love to experiment with a markdown centric spread sheet app.
At the time there was so little online info that I had to figure out everything on my own (and no chatbots didn’t have a clue about TextKit2), but STTextView was a great reference. Overall his open source work was very much appreciated. (I should probably say as much in the read me.)
That experiment was also a ton of work that ultimately didn’t go anywhere. Most people would rather just use a relatively subpar embedded browser (i.e. web view).
This is the key insight that makes TextKit2 workable. I personally would not attempt to build an alternative to UITextView on TextKit (1 or 2). Instead, TextKit2 is all about very sensible intervention points for customizing UITextView (eg, Markdown-style parsing, typography, interactions, layout).
I recently rebuilt Minimal’s editor with TextKit2 (see minimal.app/#beta to experience it), and found Kryzanowskim’s deep dives very fruitful. He explores the edges of the API, so his writing helped me identify a nice bounds of safe-space to work in, and helped clarify what areas are too complex to safely build custom functionality within. (So thank you, author!)
I would not dismiss TextKit2; it is an incredible improvement over TextKit1. It remains a complicated and challenging field.
sure. If only UITextView/NSTextView did not have bugs impossible to workaround otherwise. TextKit 2 support in UITextView/NSTextView was really bad. improved over time. and still remain buggy. The UITextView focus limits the use of TextKit 2 architecture significantly.
It's an absolute disaster on macOS. Even TextEdit app is now buggy as hell.
It's incredible how Apple broke plain text display on the Mac, which was a solved problem since forever.
I have to wonder if the scrollbar problem is inescapable, given the shape of the problem.
Flutter has dealt with similar issues, perhaps by virtue of more eyeballs / being slightly older, there are solutions. SuperSliverList in particular completely erased the jumpy-jank that happened when estimates changed to concrete values.