Custom NSTextContentManager?

[Jason-Abbott]

Does STTextView allow use of a NSTextContantManager subclass that does not use NSTextStorage?

That seems to be implied in the old Apple Developer thread but I don’t see that explicit option here.

[krzyzanowskim]

to some degree. I was working toward this goal, then at one point I realized I needed some thing akin to NSTextStorage for attributed string storage anyway and I either reimplement it or use it. I did shortcuts to fallback to it. For that reason, the default STTextContentStorage is from NSTextContentStorage. That said, this is probably the closest implementation that, with not much effort, can use different storage.

quick search show this:

if you have NSTextContentManager that is complete custom implementation I'm interested to make it work. I also wonder what is your use case for that

[Jason-Abbott]

Thanks for the fast reply. Your talks and work here have been a big help.

My use case involves a SQLite table in which each row could map directly to an NSTextElement (paragraph, heading, list item, figure, etc.) in documents that may have hundreds of pages. The rows do not have plain text. Each needs to be parsed.

This “word processor” usage looks more like @danielsaidi’s RichTextKit, I think, than STTextView.

I’d love to contribute a PR to STTextView with alternate storage support but I think the smart move is first to evaluate what the performance really looks like to fetch, parse and concatenate all the rows to NSAttributedString and the effort of mapping changes back to the rows.

If that gets stupid then I’ll try harder with custom storage, based on STTextView.

[krzyzanowskim]

NSTextStorage itself with all it's issues, is pretty good optimized for even large storage - as long as it fit the memory constraints

[colbyn]

Oh as someone who's been down this road, good luck.

I've been experimenting with building a custom backing store for an AST like data model and subclassing NSTextContentManager and getting everything to work property can be a lot of work and there's tons of little details that aren't entirely clear.

For instance in TextKit 2 everything begins with the NSTextElementProvider interface and e.g. given this signature:

func enumerateTextElements(
    from textLocation: (any NSTextLocation)?,
    options: NSTextContentManager.EnumerationOptions = [],
    using block: (NSTextElement) -> Bool
) -> (any NSTextLocation)?

The docs say:

If enumerated at least one element, it returns the edge of the enumerated range.

Maybe it's just me, but what exactly is meant by the "edge" with respect to either forward or backward enumeration?

Also I suppose it's not that big of a deal but why is a returned NSTextLocation even necessary? The systems knows the range of the whole document and it knows the range of each NSTextElement which overall seems sufficient.

---

Personally I think NSTextElementProvider is the worst part of TextKit 2. For one it assumes that all implementors want such an API that also encompasses document modifications which IMO should be specific to a given backing store and should overall be outside the scope of a generalized text rendering interface (especially since some use cases may only require read-only functionality).

Personally I think a lazy iterator like API would be far better. Something like:

public protocol ForwardElementIterator<Element> {
  associatedtype Element
  mutating func next() -> Self.Element?
}

public protocol BackwardElementIterator<Element> {
  associatedtype Element
  mutating func next() -> Self.Element?
}

public protocol ElementIteratorProvider<Element> {
  associatedtype Element:
    SSDocumentRange
  associatedtype ForwardIterator:
    ForwardElementIterator<Element>
  associatedtype BackwardIterator:
    BackwardElementIterator<Element>
  func makeForwardIterator(
    startingFrom startIndex: Element.Index
  ) -> ForwardIterator
  func makeBackwardIterator(
    startingFrom startIndex: Element.Index
  ) -> BackwardIterator
}

Or use a zipper like API for more uniform forward/backward traversal:

public protocol SSElementZipper<Element> {
  associatedtype Element: SSDocumentRange
  mutating func seek(to position: Element.Index)
  mutating func forward() -> Self.Element?
  mutating func backward() -> Self.Element?
  var currentElement: Element? { get }
  var firstElement: Element? { get }
  var lastElement: Element? { get }
}

Where each element records its logical range in the parent document (via SSDocumentRange) and its index with respect to other top-level elements (i.e. Element.Index).

Perhaps TextKit shouldn't even need to know the whole document range in favor of just fetching and rendering content via some iterator or zipper like API.

But I digress... (I've been trying to figure out how to build a higher level interface upon TextKit 2 for more custom document data models.)

Anyway I apologize for the rant. Perhaps there were some helpful tidbits with regard to your problem...

IMO learn from my mistakes and just figure out how to make TextKit 2 work with the preexisting NSAttributedString based APIs, such as using NSTextContentStorage over a custom NSTextContentManager solution which—as shown here—can be made to support very complex block types like full blown tables (that look way better than HTML tables IMO).

[Jason-Abbott]

Thanks for sharing this, @colbyn. I saw your post on r/swift as well. I’m not working on a Markdown editor but your AST models are quite similar to how my documents are stored on disk. I’ll follow your work, though for now, having made it through the stages of TextKit grief (denial, anger, bargaining, depression) and not wanting to block myself for months, I’m taking the opposite tack: treat TextKit as if only the defaults are functional.

(You appear to be doing a lot on the layout side as well. For now, I’m getting by with just a couple NSTextLayoutFragment subclasses with a couple dozen lines of code to fix lists and add some things — my only deviation from defaults.)

[colbyn]

Oh yeah if you're looking at my code, the part that actually draws NSTextLayoutFragments is super freakin messy right now so don't judge me too hard on that bit since it was developed in a very exploratory manner and I haven't yet been able to clean it up.