If a user sets ZSH_THEME_HG_PROMPT_* as the following, he ends up with
%{$reset_color%} resetting the bold style of last character ")" because
_SUFFIX was expanded before calling hg_dirty():
ZSH_THEME_HG_PROMPT_PREFIX="%{$fg_bold[blue]%}hg:(%{$fg[white]%}"
ZSH_THEME_HG_PROMPT_SUFFIX="%{$reset_color%}"
ZSH_THEME_HG_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗%{$reset_color%}"
ZSH_THEME_HG_PROMPT_CLEAN="%{$fg[blue]%})"
With this patch, the variable ZSH_THEME_HG_PROMPT_SUFFIX is lastly
displayed, following the same order as in git_prompt_info(),
i.e. <prefix><dirty><suffix>.
docker container autocomplete listing uses containers ID instead of names.
Most users identify their containers by name. ID is only needed and used on a dynamic environment more suited in scripts.
cab is a wrapper for ghc-pkg and cabal that provides some nice features
like listing outdated packages.
See https://hackage.haskell.org/package/cab for more details on the cab
program.
Ubuntu and Debian store the system-installed virtualenvwrapper in
/etc/bash_completion.d/virtualenvwrapper, so that it gets automatically sourced
at startup in Bash. By not putting it somewhere in $PATH, they end up excluding
others (e.g. Zsh) that might want to use that file. Oops!
The virtualenvwrapper plugin should account for this so that Ubuntu (or Debian)
users don't end up with this message:
zsh virtualenvwrapper plugin: Cannot find virtualenvwrapper.sh. Please install with `pip install virtualenvwrapper`.
even when they have a virtualenvwrapper installed to a known location.
This is because we can't be sure which arguments require a json file
and which don't, so the `else' statement will always be difficult to
check for correctness.
Use $_comp_command1 for command list generation instead of 'composer':
`$_comp_command1` contains the command written in the command line.
This allows us to have a different composer name
Sources the activate.sh file or informs the user, that its not
available.
Overriding the cd function, as it was formerly done, is not needed
anymore, activate.sh does this by itself.
This way the user can keep their preferred pushd syntax while enabling
us to use a standard syntax in our defined functions.
To explain further, without a clear value on the PUSHD_MINUS option, we
could be changing the +1/-0 values all we want, that some user would
find that it didn't work for him.
We have two options, then:
- Setting a particular value, which was my first approach.
- Using `emulate -L zsh` to ensure all options defined in the function's
body won't be passed along to the main zsh instance.
For more info see:
http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-emulate
This change follows this proposed behaviour:
Ctrl+Shift+Left: move to last visited directory
Ctrl+Shift+Right: move to next visited directory
an alternative behaviour would be:
Ctrl+Shift+Left: move directory to the left in `dirs` output
Ctrl+Shift+Right: move directory to the right in `dirs` output
It also introduces `setopt nopushdminus` as a way to standardise
pushd syntax. It's value wasn't clear before, which has been the
cause of so many pull requests regarding this plugin not working
in some environments.
Make use of ant's project help feature instead of trying to parse XML with regex (see: http://stackoverflow.com/a/1732454/740787).
This is a behavioral change that does a few things:
• adds support for ant imports, which were previously not recognized as possibly containing targets
• supresses targets with no description, as these are conventionally for internal use only
In the old version, the function returned true (0) if the cache file
was newer than the Cakefile, which was *always* unless the Cakefile
had been updated. Therefore we generated the file every time unless
the Cakefile was updated, which was precisely when we needed to
regenerate the cache file.
Now it generates the cache file only when the Cakefile has been
updated.
If user manually deactivates the virtualenv when using this mode, zsh
will produce following error:
deactivate:12: command not found: virtualenv_deactivate
To avoid this, check that the VIRTUAL_ENV flag is set before trying to
automatically deactivate the virtual environment.
Fixes#2185
