coverage: 83.144%. remained the same
when pulling61bd8a8 on liuyinz:fix/sort-rg-match-positions
intoe9ca15d on dajva:master.

So I assume this comes from multiple calls torg-filter, did you confirm the source of the problem?compilation-mode calls this repeatedly adding more content as it arrive so seems there could be a problem there.

I am meticulous with the performance of this code since I know this function is a hot spot. So, the usage ofcl-sort is a bit of a concern here, especially since it will be called for every invocation ofrg-filter and iterate over an increasingly larger list where most of the items should already be sorted. Did you benchmark this?

If my guess about the source of the problem is correct it should work, pushing the result to a local and then finish of with(nconc rg-match-positions (nreverse temp-list)) so that the new additions in every call torg-filter are appended to the existing list.
I assume this would be faster sincenconc is implemented in C and no comparisons with extra function calls need to be done. Can you investigate if this path should work just as well?

@dajva You are definitely right about that ! Due to multiple calls ofrg-filter,rg-match-positions need to be concated after every replacement rather than simplenreverse. I know little about elisp performance, very thankful for your patience and advice, is there any problem for latest code ? If you think it's OK, I would squash them into one commit.

It all looks fine now

Squash into one commit already, thanks for your review.

Thanks a lot for the patch. Merged