Here is a mockup on how Mention would look like as an inspector:

This will have auto-complete showing all authors in the current topic.

Some more details on what I would expect from autocompletion:

• Show initially open with a list of authors in the current topic.
• As the user types, show a list of any username matching the text (even if they are not authors in the current topic).

As the user types, show a list of any username matching the text (even if they are not authors in the current topic).

This will rock the house. :)

That bug was originally about the Flow TOC, and I would like to keep it limited to that. I also don't think this is a blocker even if it does apply to VE inspectors.

Change 196866 had a related patch set uploaded (by Mattflaschen):
WIP: Refactor and implement mention inspector

https://gerrit.wikimedia.org/r/196866

Just wanted to note my understanding that each ping will include exactly one user.

Should there be a Remove button in the inspector when you open an existing mention?

Either way I think you should also be able to remove by double-backspacing, like normal VE templates.

It still technically works (it saves right) despite that bug, but the VisualEditor displays [] where the rendered template should be, which is not very visual.

There are also some other issues, but that's the first one I'll tackle tomorrow.

Just wanted to note my understanding that each ping will include exactly one user.

Yes. The use of "@" as a shortcut should be enough to cover the case of mentioning multiple users efficiently. Having that, I would not consider adding extra steps for the default case of mentioning just one user (such as keeping the panel open after adding a mention).

Should there be a Remove button in the inspector when you open an existing mention?

I think we can follow the same model used for links to keep it consistent (more details below). I created a mockup showing the current link behaviour (but replacing icons and labels):

The main difference to consider between links and mentions is that for links, it makes sense to manage two separate elements: the text and the target. The "remove" action there eliminates the target keeping the text, and "modify" allows the same text to have a different target.

Mentions can be simpler than links. With mentions we can consider having just one element: the mention. Some details to compare this with links:

• Once you insert an element, deleting by double-backspacing should be possible and the whole mention should be deleted.
• A remove button is probably not needed, but we can keep it as a shortcut. If we provide one it should remove the whole mention (i.e., not leaving a plain "@ Cronopio" text that the user has to remove manually later).
• An "open" action that opens the user page may be useful to check if the user is the one we thought it was (similar to the one for links).
• A modify action would modify the whole mention. That is, if I change a "@ Cronopio" mention to mention Ludmilla, the text will also change to "@ Ludmilla".

From the above list the first item seems the most important. The rest can be added in other iterations if they were not considered initially, but if we do we need to consider how the behaviour is slightly different to the one for links.

Change 197475 had a related patch set uploaded (by Mattflaschen):
LookupElement: Add optional config field for suggestions when empty

https://gerrit.wikimedia.org/r/197475

Change 197475 merged by jenkins-bot:
LookupElement: Add optional config field for suggestions when empty

https://gerrit.wikimedia.org/r/197475

There's still the main WIP.

In T92588#1124551, @Pginer-WMF wrote:

Just wanted to note my understanding that each ping will include exactly one user.

Yes. The use of "@" as a shortcut should be enough to cover the case of mentioning multiple users efficiently.

I would prefer not to put the at-sign shortcut in the initial commit.

Change 196866 merged by jenkins-bot:
Refactor and implement mention inspector

https://gerrit.wikimedia.org/r/196866