starship / starship Goto Github PK
View Code? Open in Web Editor NEWโ๐๏ธ The minimal, blazing-fast, and infinitely customizable prompt for any shell!
Home Page: https://starship.rs
License: ISC License
โ๐๏ธ The minimal, blazing-fast, and infinitely customizable prompt for any shell!
Home Page: https://starship.rs
License: ISC License
The doc told me to add this line to my ~/.zshrc
eval "$(starship init $0)"
However, $0
is -zsh
when I use zsh as my login shell. The command above would throw me an error
error: Found argument '-z' which wasn't expected, or isn't valid in this context
Maybe using string substitution to remove the prefix '-' is better?
eval "$(starship init ${0#'-'})"
Create a CONTRIBUTING.md
file in the repo detailing how to get the local development environment up and running, a breakdown of the project structure, and tips for first-time contributors to the repo.
Here are some good examples from other repos:
As was suggested by @Snuggle, I think we should use a synchronous communication platform for discussions that would be noisy to have on GitHub. Since we're starting with a new stack, this could be a good way to ramp up on Rust and share learning resources. ๐
I considered a few platforms including Spectrum, Gitter, Slack, and Discord, and ultimately decided that Discord would make the most sense for the time being.
I'm open to switching to another platform if we see a good reason to.
Here's the invite link: https://discord.gg/8Jzqu3T
Implement the prompt segment containing the currently running Python version.
Should show if:
The implmentation done for spaceship can be referenced here: https://github.com/denysdovhan/spaceship-prompt/blob/cd4bd15b8bada850d8f68c664e669b844aec0519/sections/pyenv.zsh
When running zsh under the name /usr/local/bin/zsh
on MacOS, there is an error:
/usr/local/bin/zsh is not yet supported by starship.
For the time being, we support bash, zsh, and fish.
Please open an issue in the starship repo if you would like to see support for /usr/local/bin/zsh:
and I'm dumped back in to my default zprezto prompt.
Things should work fine: /usr/local/bin/zsh
is decidedly a version of zsh
.
Easy workaround for me: just make iTerm2 start the profile under the name zsh
instead of /usr/local/bin/zsh
. However, there may be certain edge cases where this isn't possible (e.g. you need a specific version of zsh for some reason or another and have to specify the absolute path).
Other potentially useful info:
/usr/local/bin/zsh
from MacOS's default Terminal will also trigger this error./usr/local/bin/fish
, on any of the systems/terminal emulators I tried.# Source Prezto.
if [[ -s "${ZDOTDIR:-$HOME}/.zprezto/init.zsh" ]]; then
source "${ZDOTDIR:-$HOME}/.zprezto/init.zsh"
fi
#Load theme
autoload -Uz promptinit
promptinit
prompt minimal
eval "$(starship init $0)"
I can't seem to find it :(
Even running a find
over my entire home directory pulls up nothing.
While I don't have a solid fix in mind, I'm making it a goal to learn a little Rust right now and I'd be happy to try to work on this (unless you think it would be easier to fix yourself). I tried implementing a quick fix using std::path::Path
, but I couldn't quite get it working before some other work dragged me away (you have to use OsString
/OsStr
to use Path
, and there's a whole lotta Options going on when trying to match.)
I believe that there could be quite a few cool improvements to the git module to make it more interactive! There are so many extra icons in nerd fonts and we could use them for different things.
Making a commit, switching branch, making a pull-request or merging? Switch to the appropriate icon!
Using GitLab or GitHub as your remote? There are also icons for that!
Thinking over the implementation of spaceship, the "section" architecture has made sense for a long time, but as the complexity of sections grew with feature requests, I think we should rethink the approach to how sections of the prompt are divided.
The kubectl
sections is a good example of where the "section" has been outgrown:
[kubectl prefix] [kubectl symbol] [kubectl context] ([kubectl namespace])
at โธ๏ธ aks1 kube-system
This model only allows for prefix, value, and suffix. The only way to compose the above section is by giving individual components to a section multiple jobs, which will make configuration more difficult down the line.
What I have in mind is the following breakdown:
Prompt
โโโ Module
โโโ Prefix
โโโ Suffix
โโโ Segment
โโโ Value
Prompt - The whole visible prompt
Module - A collection of segments. In the above example, kubectl
would be the module, with a prefix of at
. The module could contain the default styling for each segment within it. A module could have one or many segments.
Segment - A segment is an individually configurable component within a module. In the above example, kubectl namespace
would be a segment, which would inherit the styling from its module, but could have its styling overwritten through configuration or could be disabled altogether.
char
)Taking a look at kubectl namespace
in the above example, would the parentheses around the namespace be simply a part of the segment value? It would be a shame to not support configurability with regard to the parentheses being there, but maybe that level of configuration is too granular? ๐ค
I have done very little OOP, so I am very open to suggestions to feedback!
This might be a dumb FAQ, but I couldn't figure it out. I always like to have my prompts change the title of my terminals as I change directories. In the old days I added bits to PS1
that the internet told me did this, and it did. However, since trying out Starship (which I like) my title isn't changing anymore.
Is there something I can add to the toml file that will enable this?
Support for PowerShell would be extra cool!
I'd be more than happy to put together a pull request for this.
Cannot use Starship if workflow is mainly with PowerShell
Add support for PowerShell for the Starship prompt
Using zsh/fish via Windows Subsystem for Linux, and invoking powershell scripts from there. But obviously not as nice as having it in PS
Implement starship prompt configuration based on the conversation that took place in #10.
starship.toml
file placed in $XDG_CONFIG_HOME
$XDG_CONFIG_HOME
is not set, read $HOME/.config/starship.toml
Context
struct for use across segmentsSegment.name
as TOML table keyschar
symbol be replaceableStarship seems to detect a python project, however in my case, it seems to not be able to detect the version, even tho when I run python --version
I get Python 2.7.15rc1
It should show the Python version in the prompt
set -U fish_user_abbreviations
export EDITOR="nvim"
export BAT_THEME="TwoDark"
export FLUTTER_HOME=/opt/flutter
export WINEARCH=win32
export WINEPREFIX=$HOME/.wine_x86
export GOPATH=$HOME/Development/Golang
# Spacefish configuration
export SPACEFISH_DIR_TRUNC=0
# PATH configuration
set -x PATH $PATH $FLUTTER_HOME/bin
set -x PATH $PATH $HOME/.config/composer/vendor/bin
set -x PATH $PATH $HOME/.yarn/bin
set -x PATH $PATH $HOME/.cargo/bin
# Loading autojump if installed
if test -f $HOME/.autojump/share/autojump/autojump.fish
source $HOME/.autojump/share/autojump/autojump.fish
end
# Loading abbreviations if existing
if test -f $HOME/.config/fish/abbreviations.fish
source "$HOME/.config/fish/abbreviations.fish"
end
// Doesn't exists
Already dreaming about features for v2.0. ๐ด๐ญ
@sirMerr had a great idea that I wanted to share with everyone!
In order to do away with a lot of the headache associated with creating GitHub issues for bug reports, it would be pretty cool if we could pre-populate much of the issue based on the user's local installation.
When the user uses starship bug-report
, a link will be generated with pre-populated fields for the following fields:
Here's an example of how a pre-filled GitHub issue would look: Example Link
By making use of the query params accepted by GitHub when creating new issues, we can make bug reporting that much easier! ๐
Port the functionality present in spaceship for the git_branch
and git_status
segments.
The following files can be used as reference for the spaceship implementation:
https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/git.zsh
https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/git_branch.zsh
https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/git_status.zsh
To retreive repo information, we will be using git2
, which is already currently used in the directory
section.
Implement the prompt module containing the name of the current user.
Should show if:
$LOGNAME != $USER
)UID = 0
)$SSH_CONNECTION
)The color of the module should be yellow, unless the user is root. In that case, the module color should be red.
This should be implemented similarly to the Node version section:
https://github.com/starship/starship/blob/c6ee5c6ac16d360ab1a44d097c91fe9f98f20f85/src/modules/nodejs.rs
The implementation used in spaceship is a good reference to have:
https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/user.zsh
On zsh and bash, the prompt seems to get "frozen" in the directory where starship init
is evaluated, e.g. if I start the shell in the tmp
directory, the prompt is always displaying tmp
, even if I move somewhere unrelated.
Prompt should change based on current directory.
Demo in bash--same thing happens in zsh.
N/A
None
I think this is being caused because bash/zsh evaluates VAR="$(starship prompt)"
exactly once (when the variable is set) and then doesn't run starship afterwards.
I can think of two solutions to this: one is demoed in the above GIF which single-quotes the assignment to the variable, delaying its expansion until it's used in the prompt. The other would be to use a command hook (precmd
in zsh, PROMPT_COMMAND
in bash) to update the value of the variable every time the prompt is drawn. I don't have a good sense for which one would be more robust.
Implement the prompt segment showing the execution time of the last command. By default, the module will only be shown if the execution time of the last command if it took more than 2 seconds to execute.
Much like the jobs
module, each shell will likely have its own say to track and retrieve execution time, so information about the last command's execution may need to be passed in as a flag during starship init
.
The implementation used in spaceship is a good reference for this module:
https://github.com/denysdovhan/spaceship-prompt/blob/5f0a747171cd171c578f9359da517545f60cc1da/sections/exec_time.zsh
Entering the Starship repository causes a Rust panic. Possibly a duplicate of #54.
The prompt would show and there would be no panic.
Welcome to fish, the friendly interactive shell
~
โ cd ~/Code
~/Code
โ ls
starship stringrev
~/Code
โ cd starship/
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::panicking::panic
9: starship::modules::rust::segment
10: starship::modules::handle
11: rayon::iter::plumbing::Folder::consume_iter
12: rayon::iter::plumbing::bridge_producer_consumer::helper
13: std::panicking::try::do_call
14: __rust_maybe_catch_panic
15: rayon_core::join::join_context
16: rayon::iter::plumbing::bridge_producer_consumer::helper
17: rayon_core::job::StackJob<L,F,R>::run_inline
18: rayon_core::join::join_context
19: rayon::iter::plumbing::bridge_producer_consumer::helper
20: std::panicking::try::do_call
21: __rust_maybe_catch_panic
22: rayon_core::join::join_context
23: rayon::iter::plumbing::bridge_producer_consumer::helper
24: std::panicking::try::do_call
25: __rust_maybe_catch_panic
26: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
27: rayon_core::registry::WorkerThread::wait_until_cold
28: rayon_core::registry::ThreadBuilder::run
Starship 0.1.0
fish
fish, version 3.0.2
fisher
iTerm2
macOS Mojave 10.14.5
โ cat ~/.config/fish/functions/fish_prompt.fish
function fish_prompt
env RUST_BACKTRACE=1 starship prompt --status=$status
end
cat ~/.config/fish/config.fish
# Start or re-use a gpg-agent.
#
gpgconf --launch gpg-agent
# Ensure that GPG Agent is used as the SSH agent
set -e SSH_AUTH_SOCK
set -U -x SSH_AUTH_SOCK ~/.gnupg/S.gpg-agent.ssh
set PATH /Users/snuggle/.cargo/bin /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin
I was hoping to create the "starship" org, but it looks like this GitHub account has been squatting the name since 2012: https://github.com/starship.
I've made a GitHub support ticket requesting access to the name, so hopefully we'll be able to use it for our org. Before I pull the trigger, do we have any other name proposals?
Now that we have module configuration implemented for many of the prompt's modules, it would be a good time to look into implementing style configuration to be able to alter the default style values.
Style configuration would be provided in string form, specifying the color and text style to be applied. For instance, you could set a module's style to "red"
, but "bold underlined red"
would also work.
Here's an example:
[character]
style_success = "bold green"
style_failure = "red"
An alternative option would be to use an array or object to specify the color and text style, but I think that using strings would be much easier to read.
It could be really cool having Elixir (and if possible Erlang too) support on starship
This would be a handy feature to have (and this feature has already been implemented in Spacefish)
As we get closer and closer to a primitive MVP of starship, we should start discussing our approach to installing the prompt. Here are a few possible implementations that I've been thinking about. I'd be open to hearing how you would suggest going about installing starship.
starship
is added to $PATH
starship $status
Installing starship
via apt-get
or brew
runs a post-install script that appends the shell config file with a script that overwrites the prompt.
Add the following to your config file:
# ~/.config/config.fish
eval (starship init)
# ~/.bashrc or ~/.zshrc
eval "$(starship init)"
starship init
will output the following based on the shell being used:
# fish
function fish_prompt; starship $status; end
# bash
PS1="$(starship $?)"
# zsh
PROMPT="$(starship $?)"
Metric | Rating |
---|---|
Easy to implement | โ โ โ โ โ |
Easy to install | โ โ โ โ โ |
Works as expected | โ โ โโโ |
Installing starship
via apt-get
or brew
runs a post-install script that identifies the shell package managers or frameworks installed, and will install starship with the API of those respective package managers and frameworks.
## Fish is the primary prompt
# fisher is installed
fisher add starship/fish
# oh-my-fish is installed
omf install starship/fish
omf theme starship
## ZSH is the primary prompt
# oh-my-zsh is installed
git clone https://github.com/starship/zsh.git "$ZSH_CUSTOM/themes/starship"
ln -s "$ZSH_CUSTOM/themes/starship/starship.zsh-theme" "$ZSH_CUSTOM/themes/starship.zsh-theme"
# Antigen is installed
antigen theme starship/zsh
# Antibody is installed
antibody bundle starship/zsh
# zgen is installed
zgen load starship/zsh starship
Metric | Rating |
---|---|
Easy to implement | โ โโโโ |
Easy to install | โ โ โ โ โ |
Works as expected | โ โ โ โ โ |
Installing starship
via apt-get
or brew
runs a post-install script that
asks the user a series of questions to determine the correct way to install the prompt.
Similar to how rustup
is installed.
Metric | Rating |
---|---|
Easy to implement | โ โ โโโ |
Easy to install | โ โ โ โ โ |
Works as expected | โ โ โ โ โ |
I think that a mix of the last two may be the way to go. We attempt to identify the shell and package manager being used by the user, we then verify with the user (much like rustup
), and install it accordingly. The user would be able to customize the installation and override the identified shell and package manager.
It would also support a --silent
flag to simply go with the predicted method, or an installation method could be specifically chosen with flags (e.g. --shell=zsh --install-with=antigen
).
๐ @denysdovhan, @salmanulfarzy, @maximbaz, @Snuggle, @sirMerr
Howdy Spaceship/Spacefish crew! ๐
Inspired by the work @denysdovhan did on denysdovhan/robbyrussell-node and this discussion back in November, I went ahead and started work on starship two weeks ago displeased with the amount of duplicated effort that is made to maintain both spaceship and spacefish.
I'd like to discuss the possibility of consolidating our efforts, forming a Starship organization, and all working on one unified codebase that could become the next-generation shell prompt for astronauts across shells. ๐
I totally understand if there's any hesitance, a lot of amazing work has been put into creating the other projects, and this is a totally different beast in a new language for most of us (I didn't know a drop of Rust two months ago ๐ ). But, this also presents a new opportunity to start from scratch, and rethink our approach with regards to performance, safety, testing, and compatibility.
What has been made so far is purely a proof of concept, which I have no problems scrapping if we want to collectively rethink the architecture of the project.
I will personally keep working on this, putting spacefish into maintenance mode, but I would love to hear from you all about proposed next steps.
๐
Implement the prompt segment containing the currently running Rust version.
Instead of the ๐ฅ
symbol used in spaceship, I suggest we use the ๐ฆ
emoji instead, as is planned in spaceship v4: spaceship-prompt/spaceship-prompt#516
Should show if:
rustc
is available as a commandThis should be implemented similarly to the Node version section:
https://github.com/starship/starship/blob/d620f9116b2b342ff22978ae87a78cdfccefb0de/src/modules/nodejs.rs
The implementation used in spaceship is a good reference to have:
https://github.com/denysdovhan/spaceship-prompt/blob/d9f25e14e7bec4bef223fd8a9151d40b8aa868fa/sections/rust.zsh
Using a TOML configuration file ~/spaceship.toml
instead of how environment variables were used in spaceship.
I would like to reconsider how we should be doing prompt configuration. Historically we have had all configuration done with environment variables:
SPACESHIP_PROMPT_ORDER=(
dir,
ruby
)
# DIR
SPACESHIP_DIR_PREFIX='' # disable directory prefix, cause it's not the first section
SPACESHIP_DIR_TRUNC='1' # show only last directory
# RUBY
SPACESHIP_RUBY_PREFIX="ruby:("
SPACESHIP_RUBY_SUFFIX=") "
SPACESHIP_RUBY_SYMBOL=""
This has lead to a few issues:
Here's an example of that same configuration in TOML:
segment_order = [
"dir",
"ruby"
]
[dir]
prefix = ""
truncation = 1
[ruby]
prefix = "ruby:("
suffix = ") "
symbol = ""
It didn't feel like we had enough nesting to make the complexity of JSON worthwhile as a config file format:
{
"segmentOrder": [
"dir",
"ruby"
],
"dir": {
"prefix": "",
"truncation": 1
},
"ruby": {
"prefix": "ruby:(",
"suffix": ") ",
"symbol": ""
}
}
YAML also looks like a very promising option. It is arguably easier to read than TOML, but begins to be difficult to work with when you have any nesting, as it's completely indentation-based.
segment_order:
- dir
- ruby
dir:
prefix: ""
truncation: 1
ruby:
prefix: "ruby:("
suffix: ") "
symbol: ""
Where I think light-nesting will come to be useful is if we were to support individual styling of prefixes and suffixes, like in this example:
[ruby]
symbol = ""
color = "cyan"
[ruby.prefix]
color = "magenta"
text = "ruby:("
[ruby.suffix]
color = "magenta"
text = ") "
The same thing in YAML becomes difficult to parse and write:
ruby:
symbol: ""
color: "cyan"
prefix:
color: "magenta"
text: "ruby:("
suffix:
color: "magenta"
text: ") "
This programming language is close to v1.0 release (currently v1.0 RC2) and it is used by some companies, for example Status is implementing an Ethereum 2.0 client.
Its syntax is python-ish and has a package manager called Nimble.
Website: https://nim-lang.org/
With a little bit of familiarity with Rust, you should be able to pick up this issue.
Please feel free to take your time with this one and ask any starship maintainers for help. ๐
We're here to guide you on your way to mastery of the codebase! ๐
So far we have enabled configuration for many of the prompt's modules, but we haven't yet enabled users to configure the order in which the modules are shown in the prompt.
This would involve adding a configuration option for prompt_order
that would accept an array of modules by their names. This would override the default prompt order.
Similarly to how we have implemented the add_newline
configuration below it, we would be accessing a config value to change the default behavior.
N/A
I think this is a bug
cursor appears on the incorrect line when setting line_break.disabled
to be true
cursor should appear on the same line as the prompt
# ~/.config/starship.toml
[line_break]
disabled = false
It is heavily inspired by Ruby' syntax, so you can simple adapt the current implementation.
Website: https://crystal-lang.org/
Right now, Starship truncates the directory when inside a git repo to only show the segments of the path that are in that repo.
I'd like to be able to opt-out of the truncation for git repos and fall back to the general settings on truncating paths (i.e. respecting the truncation length variable in the directory module.
An option to disable truncation of the directory globally (i.e. both inside and outside of git repositories) would also solve my issue.
Prompt panics with 'index not found'
when navigating to the root of the https://github.com/tokio-rs/tokio codebase.
Prompt displays with the tokio
dirname.
N/A
N/A
An .unwrap()
should be replaced with more thorough error handling.
It's definitely a nice feature to have compatibility with most Zsh plugin managers, so that people don't have to adapt to either a new shell or plugin manager to just use our prompt.
I currently can't install this prompt using antibody, my preferred Zsh plugin manager.
A one line to install the Starship prompt with my favoured plugin manager (I'm taking inspiration from the pure prompt).
I have used quite a few pre-made shell prompts in the last N years, and one thing that's always gotten to me is that it's very irritating to figure out what that weird symbol that just popped up at the edge of your prompt is. Inevitably, one of three things happens:
To this day, I still don't know what all the git symbols in my ZPretzo prompt mean--I just run git status
and worry about it there.
There ought to be an easier way to discover what all these cool glyphs mean.
A command that can be used (maybe starship explainer
) and it will explain what every part of the prompt means.
Pros: allows easy discovery of what each part of the prompt means.
Downsides:
Ideally you could mouse-hover over the prompt section to get a pop-up, but that depends pretty heavily on what terminal emulators are available.
It might be possible to hyperlink each part of the shell to a page that explains it, but (a) this also depends really heavily on the terminal emulator and (b) I would definitely click on those by accident, all the time.
The git section currently is missing an icon. I believe this is due to Nerd fonts not being installed automatically.
The git section should show the correct icon!
Starship 0.1.0
fish
fish, version 3.0.2
fisher
iTerm2
macOS Mojave 10.14.5
โ cat ~/.config/fish/functions/fish_prompt.fish
function fish_prompt
env RUST_BACKTRACE=1 starship prompt --status=$status
end
cat ~/.config/fish/config.fish
# Start or re-use a gpg-agent.
#
gpgconf --launch gpg-agent
# Ensure that GPG Agent is used as the SSH agent
set -e SSH_AUTH_SOCK
set -U -x SSH_AUTH_SOCK ~/.gnupg/S.gpg-agent.ssh
set PATH /Users/snuggle/.cargo/bin /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin
This could be handled by a package manager or an install script!
โจ My Windows computer is in storage at the moment, so I don't have the means to easily debug this issue. Any help would be appreciated!
The directory::directory_in_root
integration test fails on Windows, printing an empty string for the directory module.
An example run could be found here:
https://dev.azure.com/starship-control/starship/_build/results?buildId=849&view=logs&j=53d55d64-8509-53fa-5dcb-02bd85116cd5
Root directories print on Windows as they do on other platforms.
Create a CI script (probably with GitHub Actions), that will run the same benchmark on the branch of the PR and on master, surfacing considerable changes in build performance.
Benchmarks can be run in starship by running cargo bench
with Rust nightly.
An example of an existing Action that does this would be https://github.com/zeit/next-stats-action.
Here is an example of its output: vercel/next.js#7154 (comment)
Installed the new 0.8.5 update and now getting an exception thrown (see screenshot).
clean shell without errors
# ~/.config/fish/config.fish
eval (starship init fish)
# ~/.config/starship.toml
[git_branch]
symbol = "๏ฆ"
Implement the prompt segment containing the currently running Go version.
Use the hamster emoji (๐น) as the symbol for the module, and have a cyan module color.
Should show if:
This should be implemented similarly to the Node version section:
https://github.com/starship/starship/blob/c6ee5c6ac16d360ab1a44d097c91fe9f98f20f85/src/modules/nodejs.rs
The implementation used in spaceship is a good reference to have:
https://github.com/denysdovhan/spaceship-prompt/blob/d9f25e14e7bec4bef223fd8a9151d40b8aa868fa/sections/golang.zsh
Implement the prompt segment containing the package version of the package present in the current directory.
Should show package versions from Node.js projects from the package.json
file, in the version
key.
Should show package versions from Rust projects from the Cargo.toml
file, in the package.version
key.
The original spaceship implementation showing โ ๏ธ
when the package is missing a version was the source of a lot of confusion, so I don't personally think it should be added. I'm open to discussing the implementation.
The implmentation done for spaceship can be referenced here: https://github.com/denysdovhan/spaceship-prompt/blob/d9f25e14e7bec4bef223fd8a9151d40b8aa868fa/sections/package.zsh
I'm currently using spaceship prompt in zsh, which has vi mode indication for normal and insert mode (spaceship_vi_mode_enable
). Does starship offers vi mode indication already?
If not, I'd like to leave as feature request.
I've seen it being implemented in two ways, with dual prompts, like โฏโฏโฏ
or โฏ
for insert mode and โฎโฎโฎ
or โฎ
for normal mode (could be configurable), or with an additional section, like, [I] โ
and [N] โ
. sorin and pure prompts do the former, spaceship does the latter.
Implement logging for use when debugging and investigating issue reports. ๐ฉ
After a little experimenting, pretty_env_logger looked like a good solution for clear logging that can be easily toggled with environment variables.
Many of these logging events can be put in the Context
and Module
builder methods, keeping our module implementations nice and clean.
For logging events that can't be easily hidden away in builder methods, we can create macros to produce clear logs for common events.
One example would be the various checks we make when looking for files of a certain type. Here's a macro I threw together to make checkbox-like output to show what does and doesn't meet the criteria for a language:
starship/src/modules/nodejs.rs
Lines 53 to 56 in c63d7ad
Also, let's try to get our logs looking pretty. ๐
Signale does a good job of looking stylish while being informative.
An alternative would be to generate log files instead of outputting logs based on environment variables. Since the starship prompt is stateless, it should be pretty easy to reproduce faulty prompt outputs in the same directory. That being the case, I don't think there is much need for a persistent log.
Of course, I'm open to discussing if there are other reasons to log to a file!
Not sure if it fits into alot of peoples use case but perhaps we could add a config option to show online connectivity. Just saw this lib below so most of the hard work is done.
Online Rust Library
Have a module that will show an icon with current online strength or perhaps we could use the current speeds? upload download etc.
May not be fore everyone but could be a nice little feature.
Starships are much much much faster than mere Spaceships.
(Perhaps because they use Rust for their navigational systems! ๐)
However the two emoji used in this project's description shows a rocket, a vessel powered by fossil fuels and using conventional rocket propulsion.
โจ๐
The Wikipedia article for a starship describes that:
"Fiction that discusses slower-than-light starships is relatively rare, since the time scales are so long."
And it goes on to say that the majority of Starships use faster-than-light technology such as the Alcubierre warp drive in which a potential starship would compress the space in front of it while expanding the space in front of it in order to "warp" space and time to travel between star-systems, interstellar travel, travel across star-systems.
The fastest two theorised examples of interstellar travel using somewhat conventional propulsion systems (Both using nuclear-assisted engines) are Project Daedalus and Project Longshot which would've taken approx 50 years and 100 years respectively to travel to two of the closest known stars in our galaxy and would've required a nuclear fusion rocket which does not exist yet.
In short, it's largely impractical to try to travel between star-systems with rockets.
Let's have a look at some starships in science fiction, thanks to this Wikipedia article!
The combination of :comet:
and :milky_way:
would be much more representative of a starship, showing a warp-bubble as a blurry streak across space, travelling through a galaxy at more-than-theoretical speeds.
A spaceship โจ๐ is typically capable of interplanetary spaceflight whereas a starship โ๏ธ๐ is typically capable of interstellar spaceflight and because it's moving so fast it would be a mere blurry smear of stretched-out space crossing starsystems.
What do you think, are there any emoji that's even more suitable? I'd love to hear opinions! ๐ ๐
Thank you, live long and prosper, keep being awesome! ๐
Implement the prompt segment indicating that there are currently running jobs.
The โฆ
symbol has been the default symbol for the module, with a blue module color. If there is more than 1 job running, a numbered indicator is shown with the number of jobs running.
It appears that fish has its own jobs
binary, so testing will be needed on fish, zsh, and bash to ensure that the implementation is consistent across the shells.
This should be implemented similarly to the Node version section:
https://github.com/starship/starship/blob/c6ee5c6ac16d360ab1a44d097c91fe9f98f20f85/src/modules/nodejs.rs
The implementation used in spaceship is a good reference:
https://github.com/denysdovhan/spaceship-prompt/blob/5f0a747171cd171c578f9359da517545f60cc1da/sections/jobs.zsh
Add the ability to add a character to the prompt in the case of a non-zero exit code. Other prompts use things like ๐ซ, or ๐ฅ, or a red X. Having it configurable would be best, of course.
As someone who is red-green colorblind, it is very difficult to distinguish between the green and red arrows. Watching the intro animated GIF, I didn't even realize that the prompt changed after running false
until I was reading through the documentation.
Add a configurable character to the prompt in the case of the previous command exiting non-zero.
Possibly replacing the character prompt with something else? So instead of โ, maybe an X? I'm not sure where adding or replacing would be best, and would be very happy with either option.
When I was only using starship on one machine, it was pretty easy to keep track of where I was.
Now that I have it across 4 or 5, I find myself getting confused a little too often as to which host I'm actually on.
A module like host
from spaceship, which prints out the hostname of the system.
Reference implementation: https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/host.zsh
Nothing yet.
Right now, we don't have a foolproof way to support command timing in bash, which requires both overriding PROMPT_COMMAND
and trapping DEBUG
(analagous to precmd
/preexec
in zsh).
There's no real way around overriding PROMPT_COMMAND
at the moment (and if the user is installing our prompt, they presumably don't care about their old PROMPT_COMMAND
), but breaking existing DEBUG
traps could disable other functionality that isn't related to the prompt.
It seems that no two bash frameworks handle this the same way--rcaloras's preexec framework uses a preexec_functions
array, while bash-it uses a hook to add preexec functions. Until we can support it robustly (or determine that we don't care if we break user's DEBUG traps), we'll keep it out of the bash init scripts.
The first-draft implementation of timing support for bash was as follows:
starship_preexec() {
if [ "$PREEXEC_READY" = "true" ]; then
PREEXEC_READY=false;
STARSHIP_START_TIME=$(date +%s);
fi
};
starship_precmd() {
STATUS=$?;
if [[ $STARSHIP_START_TIME ]]; then
STARSHIP_END_TIME=$(date +%s);
STARSHIP_DURATION=$((STARSHIP_END_TIME - STARSHIP_START_TIME));
PS1="$(starship prompt --status=$STATUS --duration=$STARSHIP_DURATION)";
unset STARSHIP_START_TIME;
else
PS1="$(starship prompt --status=$STATUS)";
fi;
PREEXEC_READY=true;
};
if [[ $preexec_functions ]]; then
preexec_functions+=(starship_preexec);
precmd_functions+=(starship_precmd);
STARSHIP_START_TIME=$(date +%s);
fi;
dbg_trap="$(trap -p DEBUG | cut -d' ' -f3 | tr -d \')";
if [[ -z $dbg_trap || "$dbg_trap" = "starship_preexec" ]]; then
trap starship_preexec DEBUG;
PROMPT_COMMAND=starship_precmd;
STARSHIP_START_TIME=$(date +%s);
else
PROMPT_COMMAND=starship_precmd;
unset STARSHIP_START_TIME;
fi
The most common way to handle default values for config options seems to be to attempt to look up the key in the toml, then assign a default value if that fails, something like config.get_as_type(key).unwrap_or(default_value)
. There are several potential problems I can see with this approach:
use_colour
)A possible alternative would be to create a config manager class that holds enums
of all the config options, along with their default values. You would then be able to query it by asking it for the value of the enum, e.g. we would replace
let signed_config_min = module.config_value_i64("min_time").unwrap_or(2);
with
let signed_config_min = module.get_config_value(config::min_time);
We could even start to encode things like implied arguments (if one value is specified in the config, then multiple other values are implicitly set to certain values), or incompatible arguments across modules (if doing A in one module, cannot do B in another) into this config manager, and give starship the ability to check the toml for correctness.
Advantages:
Disadvantages:
Would this seem like a net positive for us, or does it seem closer to neutral for what we have at the moment?
Sorry about all the bug reports I've been generating recently! On the bright side, this is probably the last thing that's been bothering me in day-to-day use. Unfortunately, it seems a tad tricky to fix...
In ZSH, using tab-completion with starship confuses the prompt, and causes some characters to be duplicated if there's more than one completion option. Once the extra characters are printed, the "zero point" of the shell seems to shift over, and you can no longer overwrite them. It also affect character wrapping on the right edge of the screen.
Similar behavior exists in bash, but it's a lot subtler (possibly because bash does not redraw certain areas). You have to mess with history to get it to show up.
Prompt should not interfere with TAB-completion or anything involving cursor jumps.
Replicates in a shell where the only line in .zshrc is eval $(starship init zsh)
.
None.
I don't have an idea for the solution but I think I know why this happens.
If you capture the output of starship prompt
and dump it into a file, you get the following:
^[[1;36m/private/tmp^[[0m
^[[1;32mโ^[[0m
There are 11 non-printable characters on the second line of that prompt, and the space that's left between the start-of-prompt and start-of-unerasable-characters is exactly that many characters wide.
If you disable the color setting in the characters module, both the tab-completion issue and the character wrapping issue go away:
This leads me to conclude that the shell is counting the color escape codes as "printed characters" and placing the cursor too far to the right as a result.
If we were setting PROMPT
/PS1
via a hand-coded shell sequence, the solution would be to escape characters to indicate to the shell that these sequences are zero length:
but we're not--the color codes are coming from the ANSI library, and I don't see a way to tell the library to wrap the escape codes in a shell-specific escape sequence.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.