That’s a new layout engine that currently is the default for text fields and on iOS and MacOS, but likely will be the only option some time in the future.
I'm a little confused at the part about decorative attributes being done outside of the editing transaction, saying "And they are not even aware of the transaction since they live in the NSLayoutManager itself, not in NSTextStorage". Decorative attributes like color do normally live in the NSTextStorage! Is the author implying that the colors applied to markdown characters are being done with NSLayoutManager's temporary attributes support (typically used to color misspelled words)? What would be the purpose of that?
Yes. NSTextStorage can also contain the same attributes as the temporary attributes (rendering attributes in TextKit 2).
The benefit of using temporary attributes is that changing them is very fast compared to invoking the full transaction on NSTextStorage. For example, switching between Light/Dark modes is very fast in Paper.
I would have expected a transaction to track whether any changes affect layout and avoid invalidating layout if only changing rendering attributes. I assume you've actually measured this though, and so I have to infer that this optimization does not in fact happen.
In the era of DOM documents (see notion, gitbook) I very often resort to attributed strings to do magic stuff with text parsing and manipulation. It’s such an elegant structure and I don’t understand why is so unknown.
Let’s say you have a rich text where you want to highlight all occurrences of some token or syntax. When you have tree data structures you cannot use regexps or a simple parsers, since the full text may be split in different nodes.
With attributes strings it’s trivial, you just need to move attributes accordingly and to normalize stuff at the end.
For me, as a long-time Android app developer, it was interesting to see how Apple approaches things somewhat differently and more thoughtfully.
On Android, you basically have the Layout class (and its subclasses) that does everything related to both layout and rendering, and TextView which implements some of the editing/selection logic. The only difference between EditText and TextView is that EditText enables that editing functionality already present in TextView. The problem with this rather monolithic approach (and poor APIs) is that if you need more control over how your app renders text, you're out of luck. Want to get at the individual glyphs after they've been laid out for example? Nope, sorry.
That makes me super curious about it. I've only had some small interaction while learning SwiftUI and I was confused in passing, and sort of just smashed things until it worked.
Did you ever have to store custom metadata in NSAS to file? Before chatGPT, I had to write NSSecureCoding classes by hand, and that agony will remain in my soul next incarnation.
It's mostly about removing stuff from HTML - JavaScript, forms, and various CSS features - to make it focus on simple formatting. Then requiring the appropriate CSP security constraints to ensure privacy/security. Finally, standardizing on a way to include binary files (images, etc.) in the format using a JSON blob at the end of the text which can be referenced above.
Self contained, document focused, cross platform, secure and private, while still being standard HTML. Would replace ePub, .docx, Markdown, and provide a standard file format for Google Docs to export to.
Depends on what you call “similar”. They’ll have storage, layout, a part of the layout that’s visible, etc, but they may not separate them that clearly, and won’t have that rich an API. TextView is way more flexible than what the typical _text_ editor needs. Text editors typically don’t need multiple fonts, multiple font sizes, varying line spacing, paragraph indents, proportional fonts, right-aligning or decimal tabs, images inside text, etc.
All those features make TextView relatively slow and memory hungry. Because of that, I don’t think _text_ editors that handle multi-megabyte files will use a single NSAttributedString to store the entire document’s text.
That depends on the extent on which they rely on the system-provided frameworks. When the needs of the editor get specialized enough, all sorts of hackery happens.
It's a real shame that Apple doesn't release the source to a recent version of TextEdit. Given its structure (more or less just a stock objects from the API) it would be super educational for anyone who wants to use NSTextView et al.
For the educational purpose of modern TextKit and NSTextView-like implementation, you can check out https://github.com/krzyzanowskim/STTextView that is modern re-implementation of the text view.
Yeah, you can get pretty close to TextEdit by just dropping an NSTextView into the document window XIB of a document-based Mac app, hooking up the data methods in your Document class to it, and doing a little bit of wiring of menu items to the textview. Text formatting bar, rulers, Find in Page, font panel, etc. There’s a few things missing but not a ton.
The document-based app template gets you a lot for “free” too, including tabs and conversion of windows into tabs and vice versa.
The author did a great job using images to convey the various concerns each piece of code in the API is responsible for. Also super great detail in the writing. Nice work!
This feels like a technical-first article that also happens to generate goodwill for the product, as opposed to a marketing-first technical article that serves up the bare minimum of insights.
This is amazing content marketing. Developers are an obvious target niche for such a product. Exposing internals of the software in a way HNers enjoy sounds like a great idea, would love to see if it worked as a traction experiment.
I would not say that developers are the target niche. The best customers are professional writers who use a ton of writing apps for different occasions.
Professional writer who uses different writing apps for different occasions is me exactly. I’m also the (or at least a) guy who messaged you about inline comments. As soon as all the details of that feature are implemented, I’m buying it.
casual opinion; To the App developer (Mihhail L/@_mihhail?) themselves, to say: Loved just how it keeps itself, everything-from-the emoji of engineering, engi-peeping, mechanical heading–towards focus on screen/container mixed with data storage.
Never certain how it keeps for scrolling; the issue lies in drag, doomscrolls, scrollbar versus tap-for-scrolling… now, on topic of moving on: “a good OS citizen, you should provide many formats”, not keen on everything/too-many Media Formats keeping it sweet, simple; some of these Apps can become almost utility goto. Some of my favourites, include emoji meets paste formatting issues in export. How do they render correctly the almost, "interstitial flickering" change.
My expectations paused at Themes/Theming (not really happening? different looks) no simple mention of light Vs. dark; willow filter adjustment tones? Okay! Still, amazement. I believe, we choose our (kind of) Paper whenever possible.
…Thanks!
All the kindest of regards, from reading nerdy happenings! Kai V (@kaichanvong)
There are several elements that are practically invisible though: play/pause buttons on the sides, comments in parentheses, explanatory text on graphics.
It's a shame because otherwise the presentation is really good.
The play/pause buttons are meant to not disturb the reading. They are only for the rare occasions when you want to pause the video to examine it closer.
Comments can be hovered over to make them fully visible.
