Skip to content

Conversation

gabritto
Copy link
Member

@gabritto gabritto commented Sep 2, 2025

Haven't removed the collator package because presumably we'll need it for organize imports.

Collator sorting is slow, and using non-locale aware sorting doesn't seem like it would noticeably impact the user experience. For instance, vscode sorts its completion items by using regular string comparison on labels: https://github.com/microsoft/vscode/blob/8ee3a001179ba5153d152a3256c10158e18e42f9/src/vs/editor/contrib/suggest/browser/suggest.ts#L338

Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR removes locale-aware sorting from completions to improve performance. The change replaces the collator-based string comparison with a simple case-insensitive then case-sensitive comparison approach.

  • Removes locale-aware collator usage from completion sorting
  • Adds a new string comparison function that performs case-insensitive comparison first, then case-sensitive as a tiebreaker
  • Updates both the language service and test utilities to use the new comparison approach

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File Description
internal/stringutil/compare.go Adds new CompareStringsCaseInsensitiveThenSensitive function for non-locale-aware sorting
internal/ls/completions.go Removes collator-based sorting and uses new string comparison function
internal/fourslash/tests/util/util.go Updates test utility to use new comparison function instead of collator

Comment on lines +3302 to +3305
compareStrings := stringutil.CompareStringsCaseInsensitiveThenSensitive
result := compareStrings(*entryInSlice.SortText, *entryToInsert.SortText)
if result == stringutil.ComparisonEqual {
result = compareStrings(entryInSlice.Label, entryToInsert.Label)
Copy link
Preview

Copilot AI Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The compareStrings assignment is unnecessary since the function is only used twice. Consider calling stringutil.CompareStringsCaseInsensitiveThenSensitive directly in both places to reduce code complexity.

Suggested change
compareStrings := stringutil.CompareStringsCaseInsensitiveThenSensitive
result := compareStrings(*entryInSlice.SortText, *entryToInsert.SortText)
if result == stringutil.ComparisonEqual {
result = compareStrings(entryInSlice.Label, entryToInsert.Label)
result := stringutil.CompareStringsCaseInsensitiveThenSensitive(*entryInSlice.SortText, *entryToInsert.SortText)
if result == stringutil.ComparisonEqual {
result = stringutil.CompareStringsCaseInsensitiveThenSensitive(entryInSlice.Label, entryToInsert.Label)

Copilot uses AI. Check for mistakes.

return strings.EqualFold(s[len(s)-len(suffix):], suffix)
}

func CompareStringsCaseInsensitiveThenSensitive(a, b string) Comparison {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do this instead of just insensitive entirely? Is insensitive not a total order or something?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. "Ab" and "ab" are going to be equal under case insensitive comparison, but we still want one of them to be consistently sorted before the other for the tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, it's concerning that our case insensitive sort isn't correct, then

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it really depends on what you're using it for. If you're using it to, say, dedupe paths in a case insensitive FS, then "Ab" and "ab" should be equal.

Copy link
Member

@jakebailey jakebailey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable for now, in any case

@gabritto gabritto added this pull request to the merge queue Sep 3, 2025
Merged via the queue into main with commit 98d2daf Sep 3, 2025
22 checks passed
@gabritto gabritto deleted the gabritto/sortCompletions branch September 3, 2025 16:43
Harsh1925 pushed a commit to Harsh1925/typescript-go that referenced this pull request Sep 9, 2025
zshannon pushed a commit to zshannon/typescript-go that referenced this pull request Oct 6, 2025
zshannon pushed a commit to zshannon/typescript-go that referenced this pull request Oct 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants