-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Treat autocompletions as tokens with editing boundaries #6577
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
b1a8d13
2db29d8
6ecb723
8eef449
6a4f2c9
20bb619
137f9b6
9e8758b
5aa39e0
62751a8
6a94706
5995871
80e2234
0c0f470
9380f6d
23d2d93
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -234,12 +234,15 @@ export class Autocomplete extends Component { | |
| insertCompletion( range, replacement, completerName ) { | ||
| // Wrap completions so we can treat them as tokens with editing boundaries. | ||
| const tokenWrapper = document.createElement( 'span' ); | ||
| tokenWrapper.innerHTML = renderToString( replacement ); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if the replacement is an element? Should we maybe only wrap in a span when it's a string?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, @iseulde, I think that's a great suggestion. If a completer wants to insert custom HTML, it could, and we wouldn't interfere by wrapping it in a token span. I am out of time today but plan to address this in the morning.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, I'm not sure what to do here because, even if we don't wrap with a span, we probably want editing boundaries for any autocompletion. What do you think? Should we add a class to the element if a completer returns one? What if a completer returns a fragment? This may have been the line of thinking I followed to wrap everything in a span, though I understand not all elements are valid children of a span.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. After sleeping on this, my thinking is:
What do you think, @mtias?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It sounds like there could be two types of completers, but given lack of examples of the second kind, we could optimize for the cases we have now.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here is an example of the second kind where a completer is used to insert an abbreviation: In this case, the completion does not include the trigger prefix, and its
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good to me. |
||
|
|
||
| // Remember the completer in case the user wants to edit the token. | ||
| tokenWrapper.dataset.autocompleter = completerName; | ||
|
|
||
| // Add classes for general and completer-specific styling. | ||
| tokenWrapper.classList.add( 'autocomplete-token' ); | ||
| tokenWrapper.classList.add( `autocomplete-token-${ completerName }` ); | ||
|
|
||
| tokenWrapper.innerHTML = renderToString( replacement ); | ||
|
|
||
| const existingTokenWrapper = this.getTokenWrapperNode( range.startContainer ); | ||
| if ( existingTokenWrapper ) { | ||
| /** | ||
|
|
||

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we have a native tinymce API for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are TinyMCE APIs for this, but I'm guessing this component shouldn't depend on TinyMCE? Only the
RichTextcomponent is aware of it. This is similar to writing flow which has tried to avoid using TinyMCE APIs. If we want we could pass theeditorinstance though.