Repository navigation
Replacing a mention placeholder when a new one is inserted does not work when using display-name-based mentions #6950
Description
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:
Activity
robertknight commentedon Apr 4, 2025
Related comment: #6859 (comment)
acelaya commentedon Apr 4, 2025
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 commentedon Apr 4, 2025
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 commentedon Apr 9, 2025
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:
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 commentedon Apr 11, 2025
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:
@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.
@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.
USERNAME_MENTIONS_PATandDISPLAY_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_PAThas 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.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.