Replacing a mention placeholder when a new one is inserted does not work when using display-name-based mentions

[acelaya]

When the caret is moved over an existing mention placeholder in the annotation textarea, if a new suggestion is selected, it is supposed to replace the mention "under the caret" with the newly selected one.

This works as expected with username-based mentions, but it doesn't work with display-name mentions.

Username-based:

replace-username-mention-2025-04-04_11.36.15.mp4

Display-name-based:

replace-display-name-mention-2025-04-04_11.37.41.mp4

[robertknight]

Related comment: #6859 (comment)

[acelaya]

Related comment: #6859 (comment)

I think we can do that (and probably should), but that still doesn't fix the issue entirely.

For example, if you remove the last character of a mention, GitHub displays suggestions again for those matching the remaining part of the mention. In our case, if that's the closing bracket, that creates a situation where we no longer can really tell if the caret is "inside" a mention.

But yeah, I think we should start with your suggestion from #6859 (comment), as it will at least simplify the cases to handle, and then see if we can in fact support that in the LMS as well.

[acelaya]

Also, for future context, there's a bit of extra discussion around this issue in our company slack https://hypothes-is.slack.com/archives/C4K6M7P5E/p1743774615330639

[acelaya]

This also affects usernames with dots in the web app, because the logic to determine if the caret is "inside" a mention, looks ahead for an @ character, but skipping any boundary character, which includes [ and ..

I think the way to fix this is to change to logic to determine if the caret is inside a mention, using the existing mention regexps we use to match in other contexts, although it has two considerations:

1. In the LMS, if the closing bracket is removed, we'll no longer be able to tell we are inside of a mention. I think that's ok, as this is probably an edge case.
2. In the LMS, when creating a mention, we match without the open bracket, as brackets are something we add only when the mention is finally inserted.
   However, when editing an already applied mention, the bracket will be present, so we need the matching to somehow work with and without the opening bracket.

[acelaya]

I've been poking at this without a lot of success, but at least I have a better understanding of the problem and the decisions that have led us to this, so I'm going to drop some notes here.

We have a couple of helper functions which are used every time text is input in the annotation textarea, but with two different purposes:

1. Check if an @ character has been introduced, displaying suggestions matching the content following this if so.
   This would be the case in which a new mention is in the process of being created.
2. Check if we are "editing" an existing mention (this also checks if the caret is preceded by a @ character, without a boundary char in between), so that once a suggestion is selected, we replace the previous suggestion with the newly inserted one.

The second case is the one failing, but the reason is that we are trying to treat both cases the same, which was almost ok for username-based mentions (except if they include a dot), but it's not for display-name-based mentions.

I believe the solution involves somehow detecting which of the two above is "happening", and trying to match differently.

1. For new mentions everything should continue working the same.
2. For edited mentions we need to do the matching against actual mention patterns (USERNAME_MENTIONS_PAT and DISPLAY_NAME_MENTIONS_PAT, but the tricky party is in reliably detecting this.

For point 2, I tried doing a "fallback" approach, but there's also no strict and reliable enough condition which can be used to determine one of them didn't work, and fall back to the other in that case.

On top of this, there are some extra considerations:

• USERNAME_MENTIONS_PAT has a requirement, which is that usernames have at least 3 characters, so we may need to use yet a different expression that doesn't have this "limitation", while still matches when the username has a dot.
• Detecting if the caret is "inside" a mention being edited has two purposes, 1) knowing what part has to be replaced when another mention is inserted, and 2) determining the filtering term for suggestions.
  In 2), determining the text depends on the mention mode, as for display names there's an opening bracket after the @ that we want to discard.