Nerdy internals of an Apple text editor

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

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

The UI of this doc is absolutely beautiful

I love articles like this.

This is great, I think it supplants https://www.objc.io/issues/5-ios7/getting-to-know-textkit/ as my go to introduction to TextKit.

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?

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've been loving this app, It's replaced all other markdown apps for me including obsidian and ia Writer!

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.

Anyone know of a similarly well crafted app for Android?

The TextEdit app consists almost entirely of a single TextView

I believe WordPad is the Windows equivalent, based on the RichEdit control.

Another fun fact is that RTF is basically the serialized form of NSAttributedString.

The same is true of Windows' RichEdit control. In fact, it looks like Windows' implementation came first: https://en.wikipedia.org/wiki/Rich_Text_Format

Imagine going through all that effort, and then saving the output in Markdown. It's like finishing your astrophysics PhD and then getting a lobotomy.

Just to repeat my years-long crusade of yelling at clouds, we need a cross platform, Rich Text HTML Document standard.

I wish there was documentation like this for more ios components!

Awesome description! Thank you!

What a great article (and personally timely, wrangling NSTextViews at the moment).

How did you glean the information needed to write this? Other people’s code? Painful experience? developer.apple.com?

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.

Is openGl used here at all for rendering?

Haha! Love this so much.

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.

I clicked "hide these widgets" from the three dot dropdown menu on your animations and now I can't figure out how to bring them back. heh.

Great post btw!

As someone who has attempted to write their own text editor completely from scratch before, this would've been a tremendous resource to have.

Discussion for the first article:

https://news.ycombinator.com/item?id=38866170

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)

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.

Oh thank god at least somebody is doing Cocoa in 2024.