Starship: Advanced Format String Configuration

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.

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.

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.

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