Having a newline there means that an empty newline is printed everytime
the user runs a command or presses Enter, which for short commands
and/or small terminal windows can noticeably decrease the information
density.
This creates a custom logger for the log crate which logs everything to a file (/tmp/starship/session_$STARSHIP_SESSION_KEY.log) and it logs everything above Warn to stderr, but only if the log file does not contain the line that should be logged resulting in an error or warning to be only logged at the first starship invocation after opening the shell.
* docs: Update git_status module docs
Have updated the configuration docs for the `git_status` to remove a
non-existing option and to add an example for how to achieve the same
effect as with the new format strings.
* Add git_status changes to migration guide
Have added the change to the sync count to the migration guide. I also
corrected a few typos in the configuration.
The default `disabled: true` is actually only available within the module (when the config struct is used and not the user toml) but not all (the hg_branch) modules checked it there again.
Document this in all places and add the check (+ test) to the hg_branch module.
* add the exit code module
this allows to display more precisely the last command exit code
and to configure starship to not change the last charcter of the
prompt even in case of failure. It is disabled by default, because
it seems a bit redundant with the character module in its default
configuration.
* rename exit_code module to status
* Enforce a default disabled=true
In the outer places, we only check for the disabled flag in the config toml file, only when this is loaded into the real config struct, we see the default. And if the default is true, we have to abort at that place. For status and hg_branch that wasn't so. I also commented the rest
* fix spaces in markdown table for status module
* Add a tip that status module is disabled by default
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Remove unrelated changes for default disabled=true
Co-authored-by: Gaëtan Lehmann <gaetan.lehmann@gmail.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Start writing migration guide
* Add prefix/suffix migration to guide
* Update docs/migrating-to-0.45.0/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Update docs/migrating-to-0.45.0/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Add missing quote
* Detail the modules affected by the change
* Document character and time migration
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* feat: Add computational duration to all computed modules
This also means that in case we do some computations and these end up empty, we submit an empty module
* feat: Add timings subcommand
This outputs the timings of all computed modules, sorted by the duration it took to compute the module.
Useful for debugging why the prompt takes so long.
* feat: Add timings to explain output
* fix: Ensure that even empty custom modules get timings
* format main.rs
* feat: Only show interesting timings
* fix(tests): Change tests to look for empty string instead of None
* Use proper wording in timings help
* Revert "fix(tests): Change tests to look for empty string instead of None"
This reverts commit aca5bd1b03c48e1dee1b7ca91d66e2bda2d5a97c.
* fix(tests): Returning None in case the module produced an empty string
* fix: Ensure that linebreaks (and space) make a module not-empty
* Make cargo clippy happy
* Make Module.duration a proper Duration
* Only return a module if we would report it
* Change to cleaner way to return None for empty modules
* Avoid unnecessary module creation
* Simplify a string comparison
* Add timings to trace
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Have restored the `pyenv_prefix` option to the python module. This is
added as a new variable that will only be shown if `pyenv` is being used
to determine the version of python that is being used.
Previously the prompt function used in PowerShell would overwrite the $LASTEXITCODE and $? automatic variables that were set by the previous command run the user in the shell. This results in surprising behavior for the user if they inspect those variables looking for the result of the command they last ran.
This fixes the bug reported here: https://github.com/starship/starship/issues/1051
And goes further to also propagate the $? automatic variable which is not mentioned in that bug.
Previously, all modules would have prefixes, which lead to the first
module having a dangling prefix. This change ensures that the first
few modules would instead have suffixes so that we don't start or
end with a prefix or suffix.
* docs: Clarify that commands will be passed in on stdin
* docs: Clearer instruction how to include individual custom modules
* docs: Include link to #1252 in docs for custom modules
That issue is used to share custom modules.
* docs: Remove reference to prompt_order
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Convert-Path in the powershell prompt script works with -Path,
which interprets paths as wildcard patterns.
Not all valid paths are also valid wildcard patterns, possibly causing
the prompt to error (eg []*).
Replace it with -LiteralPath that makes Convert-Path use the path as-is.
We have had a few issues where users haave run the install script and
have ended up with a non-functioning version of starship because their
system doesn't have a required lib that we link against. To avoid these
problems it seems the easiest solution is to default to using the
statically compiled musl binaries. If a user knows that they are doing
they can use the non-statically compiled binaries by supplying the `-p`
argument to the installer. Note this is what other rust based tools such
as ripgrep do.
The hostname module does not provide any "number" variable, its presence
in the documentation is likely due to some copy&paste from the jobs
module section, so let's drop it.
Signed-off-by: Emanuele Aina <em@nerd.ocracy.org>
