dotnet-suggest: Don't duplicate registration entries, don't return false matches, and be more careful about casing
メンテナーはふだん 1 日以内に返信
評価
調査の方向性
dotnet-suggest の登録と FileSuggestionRegistration.FindRegistration() から始め、特に登録パスとプレフィックス検索ループを確認します。重複エントリ、最初の一致と最後の一致、偽のプレフィックス、プラットフォーム間の大文字と小文字の扱いについて、現在の動作を検証します。完了条件は、登録で重複を回避し、検索が意図したエントリのみを返して不要に継続せず、大文字と小文字の扱いが選択したプラットフォームの動作に従うことです。
索引モデルが issue の本文から書いたものです。
説明
dotnet-suggest is pretty simple in its handling of registrations.
It's just a utf-8 text file with one executable path per line that gets scanned line by line from start to end when searching, returning the last "match" found (which is also just a StartsWith match, and thus can return false positives), and which blindly appends to the file on registration, so long as the provided path exists. It also performs its search explicitly as StringComparison.OrdinalIgnoreCase.
These have a few undesirable consequences:
- Entries are duplicated if the same value is given to
dotnet-suggest register --command-path <command-path> - The search for a match continues even after a match is found.
- False matches can be returned, such as if there is a registration for
/path/to/fileand/path/to/fileThatIsNotTheOneYouWant, which will return the last of those two entries, even if it is/path/to/fileThatIsNotTheOneYouWantbut it was searching for/path/to/file. - The
StringComparison.OrdinalIgnoreCasestring comparison can result in invalid completions on case-sensitive file systems, which could lead to failure to launch the target to retrieve the completions for it, if the command line text does not match the case of the actual executable but does match the case of the entry in the list. Further, if two files differ in name only by case (which is also legal on Windows, BTW), or if you have a directory structure that looks like the following example, false matches can also occur:
/a/b <-- This is a file named b in directory /a
/a/B/c <-- This is a file named c in directory /a/B/
Searching for /a/b will, with the current code, return the second entry as the match, due to both the case-insensitive search and the last-one-wins match strategy.
(1) can be avoided at registration time by just making sure the entry doesn't already exist. It doesn't really matter if the registration operation is made more expensive by doing so, because registration isn't being done frequently, and isn't being done in a context where a brief delay to perform that scan is objectionable.
(2) and (3) can be resolved by returning as soon as a match is found.
It seems to me that it is most important for it to be optimized around the search case, since that is what gets invoked more frequently and in a context wherein the user expects as little delay as possible.
(4) just needs to either have an OSPlatform guard to perform case-sensitive searches on not-windows and case-insensitive searches on Windows, or else simply always perform StringComparison.Ordinal searches on all platforms.[^SensitiveSubject]
There are plenty of other pretty low-complexity ways to make it even smarter than the above simplistic suggestions, such as maintaining the list in sorted order when registering and then performing searches by binary search, and/or by using fixed-width lines to make seeking within the file possible without having to read the whole thing into memory (which would make doing a binary search even more efficient for example). But even just de-duplicating it and returning the first prefix match rather than scanning the entire file and then returning the last prefix match indiscriminately would be improvements over the current implementation, and actually result in fewer lines of code than are currently there, since that temporary string variable named completionTarget in FileSuggestionRegistration.FindRegistration() would go away entirely, along with the extra check for that variable being null that is after the loop.
[^SensitiveSubject]: Windows is case-aware and file naming is case sensitive in Windows, so this would be the most technically correct (the best kind), though of course there is the obvious argument that, since everything else about Windows is case-lenient, enforcing case-sensitivity could be confusing, due to user expectations.
- 主要言語
- C#
- スター
- 3.7k
- フォーク
- 434
- 平均マージ
- 6時間 27分
- マージ済み PR（30日）
- 2
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
dotnet/command-line-api のほかの issue
-
German localization is incomplete対応中かも @b-v-d-e-v が 18 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
dotnet/command-line-api#2852 ·
メンテナーはふだん 1 日以内に返信
-
Incomplete French (fr) translation: RequiredOptionWasNotProvided not translated対応中かも @JPBlanc が 116 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
dotnet/command-line-api#2822 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
dotnet/command-line-api#2792 · コメント 2 件 · リアクション 16 件 ·
メンテナーはふだん 1 日以内に返信
-
`Argument.Arity` modify internal state on first get access.対応中かも @zjdangge が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
dotnet/command-line-api#2704 ·
メンテナーはふだん 1 日以内に返信
-
GetCompletions should check exit code of invoked application対応中かも @baradgur が 1287 日前に担当しました。 オープンArea-Completions bug help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
dotnet/command-line-api#2137 · コメント 1 件 · リアクション 3 件 ·
メンテナーはふだん 1 日以内に返信
dotnet/command-line-api の issue をすべて見る
似ている issue
-
bug priority: P2
難易度 1/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
メンテナーはふだん 1 日以内に返信
-
[Docs] README/PRIVACY still name AppCenter although v1.5.6.0+ uses the Microsoft Store Services SDKオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
Azure/azure-sdk-tools#17317 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
swisstopo/swissgeol-boreholes-suite#3086 ·
メンテナーはふだん 1 日以内に返信