Skip to content
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

Styles in git_metrics are not applied in nested groups #4327

Closed
m-haug opened this issue Aug 30, 2022 · 1 comment · Fixed by #5120
Closed

Styles in git_metrics are not applied in nested groups #4327

m-haug opened this issue Aug 30, 2022 · 1 comment · Fixed by #5120
Labels
🐛 bug Something isn't working as expected.

Comments

@m-haug
Copy link

m-haug commented Aug 30, 2022

Current Behavior

When using $added_style or $deleted_style in nested groups in the git_metrics module, it appears that these styles are not applied correctly. Concretely, the below configuration produces the default, white on black style.

Expected Behavior

I would expect the configuration to produce green or red on light orange, as specified by the configuration.

Additional context/Screenshots

If I remove the outer text group, the styles get applied correctly.

Environment

  • Starship version: 1.10.2
  • zsh version: zsh 5.8.1 (x86_64-apple-darwin22.0)
  • Operating system: Mac OS 13.0.0
  • Terminal emulator: iTerm.app 3.4.16
  • Git Commit Hash:
  • Branch/Tag:
  • Rust Version: rustc 1.63.0
  • Rust channel: release
  • Build Time: 2022-08-19 02:43:05 +00:00

Starship Configuration

"$schema" = 'https://starship.rs/config-schema.json'

format = """
$git_metrics
"""

[git_metrics]
added_style = "bg:#FCA17D bold fg:#00FF00"
deleted_style = "bg:#FCA17D bold fg:#FF0000"
disabled = false
format = "[([+$added ]($added_style))([-$deleted ]($deleted_style))](bg:#FCA17D)"
@m-haug m-haug added the 🐛 bug Something isn't working as expected. label Aug 30, 2022
@Ajpantuso
Copy link
Contributor

To be precise about the issue the outer style should not have altered the background of the inner styles since the inner styles take precedence as a whole i.e. the background component cannot be added in isolation from the outer scope.

What is definitely an issue however is that the style variables are not being applied when the outer style exists hence the default "white on black" style observed by the OP.

This is reproducible with an additional test in string_formatter.rs

    fn test_style_variable_nested() {
        const FORMAT_STR: &str = "[[text]($style)](blue)";
        let inner_style = Some(Color::Red.bold());

        let formatter = StringFormatter::new(FORMAT_STR)
            .unwrap()
            .map_style(|variable| match variable {
                "style" => Some(Ok("red bold".to_owned())),
                _ => None,
            });
        let result = formatter.parse(None, None).unwrap();
        let mut result_iter = result.iter();
        match_next!(result_iter, "text", inner_style);
    }

The test fails because the resulting style for "text" is empty after parsing.

I'll see if I can find a reason for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working as expected.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants