Stabilised the output of splitRangesOnEmojis

[shubham1206agra]

Details

This PR stabilised the output of splitRangesOnEmojis (made it sorted) since the input should be sorted to make this function work properly.

Related Issues

Expensify/App#55115
Expensify/App#14676

Manual Tests

1. Open composer / markdown input.
2. Try to add _*😊*_ in the input.
3. Make sure emoji is formatted, and input remains the same.

Linked PRs

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[shubham1206agra]

I have read the CLA Document and I hereby sign the CLA

[shubham1206agra]

@Skalakid @tomekzaw Can you please check this PR whenever you are free?

[Skalakid]

Hi @shubham1206agra thank you for the PR! Can you please provide more details about the issue you are fixing here? I don't see any proposal in the issues that you linked and there is no manual tests in the description

[shubham1206agra]

Hi @shubham1206agra thank you for the PR! Can you please provide more details about the issue you are fixing here? I don't see any proposal in the issues that you linked and there is no manual tests in the description

@Skalakid I tried to solve the issue with splitRangesOnEmojis if we give the input in unordered format, since it will give garbage results as the function expects the input to be in ordered format. To avoid multiple sorting calls, I gave the output in ordered format so that it will be more efficient. To achieve this, I used a Queue, and checks for correct place to insert the splitted ranges so that output will always be sorted given input was also sorted.

[Skalakid]

Okay, thanks. In my opinion, your solution adds another layer of complexity to our Expensify default parser. It will be harder to maintain this code. Have you conducted any reliable performance tests on how much queue logic improves splitting logic? Executing another sortRanges function doesn't change the time complexity at all, O(nlogn + nlogn) is still O(nlogn). So we are okay with another sortRanges to the code.

Another thing is that your solution doesn't fully fix the problem. Syntaxes are still tripled when you write _*asd😭asd*_ or _*'asd😭asd'*_ (where ' is equal to `):

Screen.Recording.2025-01-13.at.13.29.02.mov

[shubham1206agra]

Another thing is that your solution doesn't fully fix the problem. Syntaxes are still tripled when you write asd😭asd or 'asd😭asd' (where ' is equal to `):

@Skalakid The problem is somewhere else in this case. Let me see if I can find the problem

[Skalakid]

Here is the PR with the temporary fix. As I wrote under the issue, feel free to change your solution and enhance how the web parser builds the HTML structure inside the Live Markdown. The solution will not only fix all edge cases connected to splitting ranges on emojis but also make the web implementation more bug-proof when working with custom parsers