Advanced Format String Configuration

[tiffafoo]

Feature Request

Is your feature request related to a problem? Please describe.

At the moment, there's no way to handle complex conditional formatting of modules. It's been discussed a few times for when someone wants a variation of the way starship handles their modules:

• Unfortunately I don't think it's worth this much complexity for the Powerline use-case. We could get around to adding advanced configuration for this in particular, but >90% of users will only be working with basic configuration.

  There is certainly room is extend the syntax to support advanced configuration, but I think that's a discussion for another time.

  Originally posted by @matchai in Module configuration with format strings #624 (comment)

• In Git Status module there could be an option to display the status dirty (the name can be changed). By dirty status I mean accumulation of other statuses, to be precise: [...]

  Originally posted by @marekkon in [Feature Request] Show dirty git status #1192

• [...] Is it possible to have git_branch module to colorize branch name text if directory is not clean (e.g. have uncommitted changes or may be other things requiring attention) ?

  Originally posted by @dvsekhvalnov Question: git_branch to colorize branch name if working there are changes? #874

Describe the solution you'd like

It would be great to allow for complex conditional formatting of modules. As to how, I'm not sure. This would be after the format strings work, and not for the near future.

Describe alternatives you've considered

In some cases, adding custom modules is a workaround but it's definitively not ideal

[jimleroyer]

It's hard to see another way than using an advanced template language. This would provide total control of the display, including ordering capabilities.

A downside to this approach is that the advanced template language will complicate configuration for most users. But that could be avoided if Starship offers the same basic config features that we have at this moment and in addition, a more advanced one that would short-circuit the former for advanced users. Hence the basic config could cover 80% of most cases with simplicity and the latter could allow for powerful customization features, for those who desire to plumb it all themselves. This could attract power users to the project while still retaining the "casual prompters" with a simple configuration mechanism.

With such approach, this could complicate the code, at least without proper necessary refactoring. From what I see though, the current string formatter approach basically builds a map of variables for small string templates scoped at the module level. To support an advanced template language, we could scope it to the entire starship command line. Hence we'd need to have a somewhat similar map of variables to throw at the template engine, except probably with a module prefix to each variable to avoid collisions.

Error handling would require proper design as well. What do we do if one variable interpolation fails? The entire prompt should not disappear ideally but rather correctly report the unresolved variable for example.

Performance issues: would there be any? We couldn't build the entire command prompt string until we have all modules resolved. We'd have to measure the different timings if any.

[matchai]

But that could be avoided if Starship offers the same basic config features that we have at this moment and in addition, a more advanced one that would short-circuit the former for advanced users. Hence the basic config could cover 80% of most cases with simplicity and the latter could allow for powerful customization features, for those who desire to plumb it all themselves.

Yep, that's exactly what I had in mind. Typical key-value TOML for simple configuration, and a DSL or nested object-based syntax for more advanced configuration. 👍

Alternatively, if the API was redesigned to be more consumable as a library, Starship could behave as a framework, exposing functions for context detection and shell prompt formatting, and let people decide themselves how it works in Rust.

[jimleroyer]

What about if we expand on the current string formatter feature, maybe with more syntax support (do we need more?). A custom re-ordering would be necessary... Sharing variables seem necessary with the use cases described in the issue. That might not work easily with that solution. On top of my head, with my limited experience on that project:

A few pros:

• A more incremental approach building on top of where we'll be soon.
• Code stays mostly the same, except maybe for the module re-ordering logic?
• No surprise in performance hit.
• Not too much documentation to change, yeah, Yes it's a pro!

A few cons:

• Complicates the existing configuration support for most cases. Power users and casual prompters will have to use the same config mechanisms.
• Sharing of variables between modules might be more a challenge or not idiomatic.
• No total control of the prompt display yet.

[heyrict]

Maybe #607 is related to this issue , which requests for conditional formatting based on environment variables.