SuperEditor popover user mentions and hashtags

[matthew-carroll]

SuperEditor should make it possible to display popovers for user mentions, hashtags, and other arbitrary tokens.

A ticket for this behavior is filed here: #736

It would be nice if we could leverage SuperEditor extension points to introduce a standalone, opt-in tagging system, kind of like a plugin.

High-level behaviors

To display popovers in the text in response to text input, the following goals need to be possible:

• Identify tokens as they're entered
• Identify when a token has been deleted
• Identify when a token is submitted or cancelled by typing the value
• Submit (and possibly alter) a token by selecting an option in a popover
• Display a popover based on the (x,y) position of one or more characters in the document (and share focus + keyboard input)

Additionally, an app probably wants to take a special action when the user selects part/all of a submitted token. This might already be possible using existing DocumentComposer notifications, but we should make sure there's a decent option.

Recognizing text input

Possible methods for identifying token input:

• Inspect a ParagraphNode any time that a ParagraphNode changes. Determine if a token was added.
• Replace the standard keyboard entry and IME entry handlers with a version that intercepts the insertion of a token.
• Create a token reporting system that reports
  • the start of a new word "some thing #|"
  • changes to a word with the caret "some thing #ab|"
  • deletion of a word with the caret "some thing |"
• A pipeline of tokenizers that run every time text is entered or deleted

Recognizing selection of an existing token

An app should be able to listen for changes to the DocumentComposer and then inspect the text near the caret to determine if a token is selected. The developer would check for a token attribution at the selected character.

Recognizing the deletion of an existing token

A token might be deleted by backspacing or deleting into the token, or a token might sit partially or wholly within a selection, which is then deleted.

An app might wish to de-tokenize when any token characters are deleted. Other apps might wish to stay tokenized as long as any of the original token characters exist.

As long as part of a token continues to exist, the answer to "Recognizing text input" should work for deletion, too.

However, the deletion of an expanded selection might require specific treatment. There might be app-specific accounting on top of the attributions in the text. As a result, token attributions might be deleted, but those deletions won't be reflected in the app's accounting.

Options for handling expanded deletions:

• App watches the document for any changes and then scans the document to ensure that all tokens still exist
• App replaces the existing deletion keyboard handler and IME handler with one that checks the deleted text for any tokens
• SuperEditor adds behavior to the existing deletion handler that reports every deleted and partially deleted token in the deleted text so that the app can respond

Displaying a popover near characters

The app adds a document overlay that positions invisible widgets around characters that it cares about.

When a popover is displayed, it anchors itself to one of those invisible widgets.

The app needs to keep the widget position synchronized with the characters in question. We should investigate how difficult it is with existing APIs to do this.

Sharing focus and input with a popover

Based on earlier investigations with shared focus, sharing focus requires a shared FocusScope ancestor. Hopefully, that's enough.

For shared input, there's the physical keyboard version, and the IME version.

Physical keyboard: when the popover appears, the app can add new keyboard handlers to the top of the priority list in SuperEditor. Then, those keyboard handlers can talk to the popover.

IME: the IME doesn't have arrow keys, but it does have an IME action button, which might be relevant. I'm not sure how we're currently handling the IME action response. We'll probably need to make it configurable, and then the app can take control of the IME action response, instead of SuperEditor.