Live data from Hacker News

Nerdy internals of an Apple text editor

papereditor.app

11–20 of 93 posts

Re: Nerdy internals of an Apple text editor

#13
post #5

Are the internals of other Mac-native text editors like TextMate similar to this as well?

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.

Re: Nerdy internals of an Apple text editor

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

Re: Nerdy internals of an Apple text editor

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

Incredible article btw

Post reply on HN