New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
commands: fix completion descriptions #15146
Conversation
Currently, zsh and fish shell completions show incomplete descriptions for certain commands. For example: docs -- Open Homebrew's online documentation (https://docs rbenv-sync -- Create symlinks for Homebrew's installed Ruby versions in ~/ This is because `Commands.command_description` produces incomplete short descriptions for the commands having a dot (from a URL or a path) in the first sentence; the dot is misinterpreted as a full stop: brew(main):001:0> Commands.command_description("docs", short: true) => "Open Homebrew's online documentation (https://docs" brew(main):002:0> Commands.command_description("rbenv-sync", short: true) => "Create symlinks for Homebrew's installed Ruby versions in ~/" We can improve the sentence splitting logic by only splitting at dots either at the end or followed by a whitespace. Now With this change: brew(main):001:0> Commands.command_description("docs", short: true) => "Open Homebrew's online documentation (https://docs.brew.sh) in a browser" brew(main):002:0> Commands.command_description("rbenv-sync", short: true) => "Create symlinks for Homebrew's installed Ruby versions in ~/.rbenv/versions" Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch.
@@ -203,7 +203,7 @@ def command_description(command, short: false) | |||
|
|||
if (cmd_parser = Homebrew::CLI::Parser.from_cmd_path(path)) | |||
if short | |||
cmd_parser.description.split(".").first | |||
cmd_parser.description.split(/\.(?>\s|$)/).first |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ZhongRuoyu Could this get a Ruby comment added above clarifying what this is doing and why? It's not obvious from reading the code alone. Thanks!
A comment here would help the reader to understand the need for this splitting logic, which is not so straightforward. Addresses review comment in Homebrew#15146 (comment). Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
This was missed in Homebrew#15146. Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
As I mentioned in Homebrew#15146, two `Cask::DSL` tests failed on my local machine, even on `master`. `git bisect` suggested that it was Homebrew#14998 that introduced those failures. It turned out that the tests here could fail under certain locale settings, like this one below: $ defaults read -g AppleLanguages ( "en-GB", "zh-Hans-SG" ) This is not actually a regression. With the aforementioned locale settings, an explicit `let(:languages) { ["en"] }` setting would result in locales being considered in the following order: `en`, `en-GB`, `zh-Hans-SG`. For each of them, the `detect` method from `Locale` is called, with `locale_groups` as `[["zh"], ["en-US"]]`, the list of locales defined in the test cask. def detect(locale_groups) locale_groups.find { |locales| locales.any? { |locale| eql?(locale) } } || locale_groups.find { |locales| locales.any? { |locale| include?(locale) } } end Neither of `en` and `en-GB` satisfies the `detect` conditions. (Note that `Locale.parse("en").include?("en-US")` evaluates to `false`.) But `zh-Hans-SG` does (because `Locale.parse("zh-Hans-SG").include?("zh")` is `true`). So, despite having `:languages` set to `en`, the Chinese locale was still used. This could be fixed by generalising the test cask's English locale settings from `en-US` to `en`. This is already the case for most existing casks: $ grep 'language "en.*", default: true' Casks/*.rb Casks/battle-net.rb: language "en", default: true do Casks/cave-story.rb: language "en", default: true do Casks/firefox.rb: language "en", default: true do Casks/libreoffice-language-pack.rb: language "en-GB", default: true do Casks/libreoffice-language-pack.rb: language "en-GB", default: true do Casks/openoffice.rb: language "en", default: true do Casks/seamonkey.rb: language "en-US", default: true do Casks/thunderbird.rb: language "en", default: true do Casks/wondershare-edrawmax.rb: language "en", default: true do Note that this should make the language stanza tests independent of locale settings, because `zh` and `us` should be able to capture all the test cases. Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
As I mentioned in Homebrew#15146, two `Cask::DSL` tests failed on my local machine, even on `master`. `git bisect` suggested that it was Homebrew#14998 that introduced those failures. It turned out that the tests here could fail under certain locale settings, like this one below: $ defaults read -g AppleLanguages ( "en-GB", "zh-Hans-SG" ) This is not actually a regression. With the aforementioned locale settings, an explicit `let(:languages) { ["en"] }` setting would result in locales being considered in the following order: `en`, `en-GB`, `zh-Hans-SG`. For each of them, the `detect` method from `Locale` is called, with `locale_groups` as `[["zh"], ["en-US"]]`, the list of locales defined in the test cask. def detect(locale_groups) locale_groups.find { |locales| locales.any? { |locale| eql?(locale) } } || locale_groups.find { |locales| locales.any? { |locale| include?(locale) } } end Neither of `en` and `en-GB` satisfies the `detect` conditions. (Note that `Locale.parse("en").include?("en-US")` evaluates to `false`.) But `zh-Hans-SG` does (because `Locale.parse("zh-Hans-SG").include?("zh")` is `true`). So, despite having `:languages` set to `en`, the Chinese locale was still used. This could be fixed by generalising the test cask's English locale settings from `en-US` to `en`. This is already the case for most existing casks: $ grep 'language "en.*", default: true' Casks/*.rb Casks/battle-net.rb: language "en", default: true do Casks/cave-story.rb: language "en", default: true do Casks/firefox.rb: language "en", default: true do Casks/libreoffice-language-pack.rb: language "en-GB", default: true do Casks/libreoffice-language-pack.rb: language "en-GB", default: true do Casks/openoffice.rb: language "en", default: true do Casks/seamonkey.rb: language "en-US", default: true do Casks/thunderbird.rb: language "en", default: true do Casks/wondershare-edrawmax.rb: language "en", default: true do Note that this should make the language stanza tests independent of locale settings, because `zh` and `en` should be able to capture all the test cases. Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?The following tests failed but I don't think they are related. (On my Mac, they failed on
master
, too.)Failures
(output truncated & reformatted)Currently, zsh and fish shell completions show incomplete descriptions
for certain commands. For example:
This is because
Commands.command_description
produces incompleteshort descriptions for the commands having a dot (from a URL or a path)
in the first sentence; the dot is misinterpreted as a full stop:
We can improve the sentence splitting logic by only splitting at dots
either at the end or followed by a whitespace. Now With this change: