MSC 3952: Intentional mentions support, expose an API to get current mentions in RTE

[Velin92]

Every time we use the insert_mention function (or similar) ti set up a mention from a suggestion pattern or not, which has the purpose of creating a Mention Node that is then used by a Client to render a Pill, we can consider that as an "Intentional Mention".

As a user of the RTE, I would like to also have a function that exposes the current Mentions state of RTE, so that when I am sending a message I can use this state to attach the intentional mentions in it.
Only the Mention Nodes that have been actively added by the client by using the insert_mention APIs should be considered as such, and should be returned.
Also this API doesn't need to keep track of the order and the presence of multiple mentions of the same user id, or if the @room mention has occurred more than once, what it matters is only if the mention has occurred at least once in the RTE message.

[aringenbach]

The node attributes we already have seems like a perfect candidate to handle this. One thing to keep in mind though is that we probably need to be extra careful around possible loss of data (e.g. if plain text toggle exists again at some point, the hosting application needs to be intentional mentions-aware, and be able to provide data to the library around what mentions in the HTML actually were intentional - and the very similar case that will probably exist soon enough, if the hosting application provides a way to restore a partial message from local DB, that restored message needs to be provided as well with a way to restore intentional mentions).

Outside of that, this seems like a pretty straightforward iter().filter().unique() over all MentionNode objects of the model.

[Velin92]

The node attributes we already have seems like a perfect candidate to handle this. One thing to keep in mind though is that we probably need to be extra careful around possible loss of data (e.g. if plain text toggle exists again at some point, the hosting application needs to be intentional mentions-aware, and be able to provide data to the library around what mentions in the HTML actually were intentional - and the very similar case that will probably exist soon enough, if the hosting application provides a way to restore a partial message from local DB, that restored message needs to be provided as well with a way to restore intentional mentions).

Outside of that, this seems like a pretty straightforward iter().filter().unique() over all MentionNode objects of the model.

Luckily we don't have such a problem for now on El-X but yeah this is something we will need to take in account in the future if we want to swap html to plain on the fly while the composer is on, thanks for flagging this! By the way I just opened up a PR where I get all the mentions node and generate a state struct that contains for now only the mentiones user's mx ids and if the room has been mentioned or not.

[aringenbach]

Yeah and actually it seems to me that my comment might be ignored just fine. I was assuming we would have some kind of mechanism built into RTE to differentiate newly added mentions in the Edit use case, but actually it might be waaaaay simpler to handle the edit use case entirely on the hosting app side by just doing something like new_intentional_mentions.subtract(old_intentional_mentions) when confirming the edition.

[Velin92]

Kamino cloned this issue to matrix-org/matrix-rich-text-editor