TextFormation

TextFormation copied to clipboard

One of the core goals of this library is to make it text-system agnostic. But it still has a few limitations in that area. Specifically:

• It relies on Apple-built text view behaviors in a few areas
• The TextInterface type is a protocol and that brings along a number of problems (like overlapping method/var names for conforming types)
• Support for multiple cursors is tricky

Not directly related to this, but it would also be cool to break the dependency on TextStory.

I've begun addressing these on a branch. But I quickly discovered that getting rid of TextStory is hard. This because a number of filters and the indentation system rely on some non-trivial string query capabilities with that package.

That core functionality has actually been useful in many of other places. So, as a first step, I'm considering further decomposing that library. This kinda makes sense, since I'd like TextStory to remain focused on NSTextStorage anyways.

But that would mean TextFormation would still have at least one dependency. And it isn't yet clear how painful it will be to not have access to Rearrange. So, from a strictly "less dependencies is better" point of view, it could be a lateral move.

@thecoolwinter, what do you think?

I like the idea of splitting from TextStory, but I'm not sure how necessary it is as you'd still need to have some string mutation protocol anyways.

I do think however that making a more 'functional' API might be helpful in solving some of the issues with relying on Apple text implementation, and make it more flexible for scenarios like multiple cursors.

What I mean is the filter API takes two parameters each time it's run:

• Text storage (or at least some reference type string)
• Mutation to apply

And it returns:

• Whether or not to apply the mutation (same enum as before)
• Array of mutations to apply (in order)
• Suggested cursor range

Which gets rid of any state and leaves the filters ready to act on whatever is needed without worrying about cursor management or any other storage specific stuff. That would allow the implementer to update the cursor location and work with multiple cursors by running the filters once per cursor and updating accordingly.

Yeah, you're right. Separating them could incur a little duplication.

I have to look, as I'm not yet sure if all the mutations a filter can make can be described in an independent way. But, I really like the suggestion!

Just wanted to provide an update, since it's been a while. Still going to do this.