Closed jwaldrip closed 7 years ago
@caiogondim Update on getting this merged?
@jwaldrip I am personally against such tests and conditional displays. What if I am in a ruby project but I don't have a ruby file in the current directory? Does my prompt vanish? Also relying on git, what if I like/have to use bazaar in the current project? And my biggest concern I always raise, what if I want to know which version of ruby (or any other interpreter) will spin up when I issue a REPL anywhere in the system.
Ruby version managers already react to the best practice, that is using the .ruby-version
file and switching according to that.
@dawikur @caiogondim any opinions?
This change re-introduce few things, looks like it contains few merged changes
First line, BULLETTRAIN_PROMPT_CHAR="\$ "
@jwaldrip why are you adding additional space here? It is handled in different place.
Second, all this re-introducing _SHOW
variables. Why? This feature was removed in favor of BULLETTRAIN_DIR_CONTEXT_SHOW
After thinking about it, I actually like the idea to hide/show segments 'dynamically', but I would love to have option to turn it on/off. Not sure yet if one global option or something with more control...
If we introduce the dynamic segments, then my guess would be, that the user type who turns it on would love to see shorter prompt already. Me who would turn it off, I don't care how long the prompt is, I want info. That idea actually standardises behaviour across the whole theme, I am voting up for it.
I have manually altered my theme in a similar manner to your PR, only in regard to python pyenv's. I want the corresponding segment to only be displayed if my pyenv differs from my system default:
elif [[ "which pyenv &> /dev/null" && "$(pyenv version | sed -e 's/ (set.*$//' | tr '\n' ' ' | sed 's/.$//')" != "$(pyenv global)" ]]; then
prompt_segment $BULLETTRAIN_VIRTUALENV_BG $BULLETTRAIN_VIRTUALENV_FG $BULLETTRAIN_VIRTUALENV_PREFIX" $(pyenv version | sed -e 's/ (set.*$//' | tr '\n' ' ' | sed 's/.$//')"
fi
I do, however, agree with @dawikur that such a feature would have to be toggleable and maybe configurable?! Which brings me to my question, really, though; should this repo be added to with a feature such as configurable, dynamic segments or is it encouraged to just run a customized fork ( @caiogondim )?
Only provide the enabled language contexts based on what the current directory/git repo contains.