Umbrella: Preparation for the release of format strings

[heyrict]

Related #624, #1021 (comment)

This is a tracking issue about thing to do after #1021 get merged.

• Refactoring prompt_order in StarshipRootConfig to use format string. (refactor: Replace prompt_order with format string #1056)

• Allow using variables in style string. [>]($prompt_color bold) (feat(format_string): Allow using variables in a style string #1130)

• (Needs discussion, as this may lead to unexpected behavior) Style overriding:

  Make

  "[text1 [text2](green)](red bold)

  renders red bold text1 and green bold text2

• Add to docs general explanations for format string (docs: Add docs for format strings #1083)

• Add migration guide or script (Implement error messaging for the prompt #1075, feat: Add migration script for format strings #1078, Create migration guide for the format string release #1404)

• Refactor modules and their docs to use format string

  • aws - refactor(aws): Use format strings #1272
  • battery - feat(format-string): add format string support to battery module #1158
  • character - refactor(character): Use format strings #1274
  • cmd_duration - refactor(cmd_duration): Use format strings #1200
  • conda - refactor(conda): Use format strings #1223
  • custom - refactor(custom): Use format string #1358
  • crystal - refactor(crystal): Use format strings #1224
  • directory - refactor(directory): Added formatter support for the directory module. #1096
  • docker_context - refactor(docker_context): Use format strings #1214
  • dotnet - feat(format_string): Add TFM support to dotnet module and update to format string #1143
  • elixir - refactor(elixir): Use format strings #1137
  • elm - refactor(elm): Use format strings #1119
  • env_var - refactor(env_var): Added formatter support for the env_var module #1180
  • erlang - refactor(erlang): Use format strings #1225
  • git_branch - refactor(git_branch): add format support #1112
  • git_commit - refactor(git_commit): Use format strings #1217
  • git_state - refactor(git_state): Use format strings #1221
  • git_status - refactor(git_status): Use format strings with lazy initialization #1085
  • golang - refactor(golang): Use format strings #1066
  • haskell - refactor(haskell): Added formatter support for the Haskell module. #1111
  • hg_branch - refactor(hg_branch): Use format strings #1226
  • hostname - refactor(hostname): Use format strings #1071
  • java - refactor(java): Added formatter support for Java module. #1084
  • jobs - refactor(jobs): Use format strings #1087
  • julia - refactor(julia): Use format strings #1073
  • kubernetes - refactor(kubernetes): Use format strings #1206
  • line_break - See refactor: Replace prompt_order with format string #1056
  • memory_usage - refactor(memory_usage): Added formatter support for memory_usage module #1182
  • nim - refactor(nim): Use format string #1359
  • nix_shell - refactor(nix_shell): Use format strings  #1229
  • nodejs - refactor(nodejs): Use format strings #1070
  • ocaml - refactor(ocaml): Use format strings #1275
  • package - refactor(package): Use format strings #1068
  • php - refactor(php): Use format strings #1215
  • purescript - refactor(purescript): Use format strings #1273
  • python - refactor(python): Added formatter support for the Python module. #1126 refactor(python): Added formatter support for the Python module (*one module only*) #1210
  • ruby - refactor(ruby): Use format strings #1072
  • rust - refactor(rust): Use format strings #1063
  • singularity - refactor(singularity): Use format strings #1203
  • terraform - refactor(terraform): Use format strings #1230
  • time - refactor(time): Use format strings #1324
  • username - refactor(username): Added formatter support for the username module #1266
  • zig - refactor(zig): Use format strings #1251

• Depracate SegmentConfig, Affix, Suffix ,once all modules use the new format system. (chore: Deprecate affix and module style #1394)

• (Future) Adds a macro format_string! that converts &'static str to Vec<Segment<'static>> at compile time.

[matchai]

Something we will need to address before making these breaking changes is a migration path. How will we inform users that their prompt configuration is no longer compatible, and how do we show them how to migrate from old configuration to the new format strings?

I've gone ahead and opened #1075, which would allow us to print a deprecation notice, and a link to a migration guide. In the meantime, I will write a migration guide to add to the Starship website.

[heyrict]

What do you think about a migration script?
It seems to me that SegmentConfig can be easily converted to a []() format. Although this may change the style of the original config file, users don't have to spend extra time tuning their config.

[matchai]

You're right. A migration script would be the most painless solution and should be relatively easy to implement.

[andytom]

Should we add a task (or multiple tasks) to make sure we have updated the documentation, both for the individual modules and a general explanation for the format syntax?

[andytom]

There is a feature branch, feat/format-string, that contains all the WIP for this issue.

[matchai]

Seeing as this is the biggest breaking change to Starship configuration in the foreseeable future, it's probably a good time to finally go v1.0.0. I kept waiting until the project felt a little more "stable", but I don't know that it'll be the case until a full rewrite (the work being done at https://github.com/matchai/starship-poc).
What are your thoughts?

[heyrict]

Well, imho, before we can finally go to v1.0.0 release, we should at least address the long waiting time in git_status. It seems a bad choice to me if users still have to wait a long time in a large git repo in stable.

Adding man pages, or config wizards, or optionally packages for different distributions (deb, AUR, etc.) may also be considered before v1.0.0.

[matchai]

As much as I agree and would like to make a big deal of "V1 STABLE 🎉", being in v0.X.X gives users the impression that any update can be breaking. If we think that the big performance bottleneck of git_status is needed before v1, we could try to rush it in before we finish format strings. 🤔