@phucdth12a are you moving the cursor into the middle of the first input and then inserting thật là and that's when he mention range is incorrect?

yes! after i choose one mention and moving cursor to before mention and typing diacritic character.
I think it in function 'shouldChangeTextIn'
When i typing u -> +1
after typing uw -> +2 but 'uw' => 'ư' (correct + 1)

@phucdth12a In my testing it appears as though the range of {26, 5} is correct. I tried using the example project and if I type in Một ngày đẹp trời and then add a mention the range is as you stated {18, 5}. If I then move my cursor to right at the start of đẹpand insert thật là I get a range of {26, 5}. If I count the characters in Một ngày thật là đẹp trời there are 26 which means the start of @zeee in this case is at location 26 which would then mean {26, 5} is correct. If I'm mistaken please let me know as I'd like to fix this issue if it exists but as of this moment this sounds like it might not be an issue. (The other way I've tested this was after inserting the additional text I moved the cursor to the start of the mention) if the range were incorrect we would be able to delete the first character of the mention without the mention being removed.

I test in source demo:
First Input: Test @steven Zweier => range { 5, 13 }
After i move cursor to the start index and typing: Một ngày đẹp trời, một Test @steven Zweier => range { 36, 13 }
but "Một ngày đẹp trời, một Test ".utf16.count = 28

and when mention @steven Zweier after spacing "Steven Zweier" => "Steven Zưeier"

Change to vietnamese keyboard
"Một ngày đẹp trời, một Test" => typing: Mootj ngayf ddepj troiwf, mootj Test

I've tried switching to Vietnamese keyboard and using the sample application but even after typing in the text provided the location of the mention is still appearing as accurate as far as I can tell. I've also tried adding the following test which is passing.

it("Should test that diacritic text can be added and retain the proper character count") {
                mentionsListener = generateMentionsListener(spaceAfterMention: false, searchSpaces: true)
                update(text: "Test @s", type: .insert, on: mentionsListener)
                addMention(named: "Steven Zweier", on: mentionsListener)
                expect(mentionsListener!.mentions.first!.range).to(equal(NSRange(location: 5, length: 13)))
                textView.selectedRange = NSRange(location: 0, length: 0)
                update(text: "Một ngày đẹp trời, một ", type: .insert, on: mentionsListener)
                expect(mentionsListener!.mentions.first!.range).to(equal(NSRange(location: 28, length: 13)))
            }

If you see something incorrect about the test above please let me know.

Can you also verify that you are trying this on the most recently release of the library.

I see the problem, so if the characters are selected by long pressing keys and choosing the character the library will calculate the fields correctly. This is why the test above is passing. However, if typing shortcuts are used (typing u and w resulting in ú) the information provided to shouldChangeTextIn is not correctly indicating the end result of the textView. The method would be told we're adding u and now w but will never say we're now replacing uw with ú. I'm not sure how to solve this issue but I see the problem now. Hopefully I'll find a solution.

I’ll continue looking into a fix for this but in the meantime I’ve opened a bug report for Apple to look into this. It looks like we don’t get the correct data being sent to the shouldReplaceCharactersInRange method in this scenario.

Apple has marked the issue as a duplicate. At the very least this is a known issue. Sadly I don’t have any insight into any additional information and am unable to find a way to hack around this.