that prompts if upstream remote branch(es) should be deleted too. As
with `git branch`, the function supports multiple branches as params,
and also the `-r`/`--remotes` param. Update `gbx` and `gbX` to use this
function.
Also update `git-stash-clear-interactive` to have multiple tests instead
of multiple nested `if`/`then`/`fi`. (Simpler syntax, IMHO)
and to have a help and a preview too.
Inspired by #192, and by having (few but) good prompt themes to serve as
starting points for the users to customize or implement their own.
Also removed the colors functions, since we don't need that. We're using
the newer '%F{red}color%f' code instead. (Actually all our themes are)
Closes#245
This complements the changes done in the last commit, and also fixes the
`glg` output, and removes the now unnecessary `--date=relative`
parameter from `glG`.
Although I insisted on the `--long-option` format on 8669a4f, I think
`rm -rf` is pretty common and recognizable, so revert to that.
Add missing aliases to README.md, and improve description of existing
ones. The main improvement is trying to be more concise, so instead of
repeating "records changes to the repository" multiple times, simply say
"commits", for example. Also try to use words that match the alias
letters, so for "gcs" say "shows" instead of "displays", for example.
as there are multiple solutions to list the lost commits and stashes,
but I could not find reliable ones. See
https://stackoverflow.com/q/89332/2654518.
Well, the current `git-commit-lost` and `git-stash-dropped`
implementations don't accurately work at least on the repositories I'm
working with.
The `git-hub` functions where removed at dcc3265, but aliases and docs
remained. Remove these.
Remove line break from `_git_log_oneline_format`, so it really occupies
one line. And change date format in `glG` output from committer date
(`%cd`) to relative author date (`%ar`) to conform with other formats.
Refactor remaining functions. Most of the changes refer to using the
already existing git error messages and return codes, instead of having
code that creates that. (Error messages for 'not in a git repository'
where not even consistent among functions, and there's were I started
this...)
The most drastic changes can be seen in `git-root`, then in `git-dir`
and `git-stash-clear-interactive`.
since we already have a function (`coalesce`) defined and both can now
get zcompiled into the same digest file.
Also, nest the `git-action` function to the scope where it's used.
and `RPS1`, instead of `PROMPT` and `RPROMPT`, as suggested by the zsh
manual at `man zshcontrib`, under "Writing Themes":
> By convention, themes use `PS1`, `PS2`, `RPS1`, etc., rather than the
longer `PROMPT` and `RPROMPT`.
instead of a big single `functions.zwc` file containing functions from
all the `functions` subdirectories.
This solution here better suits the functions autoloading mechanism in
zsh, as documented in
http://zsh.sourceforge.net/Doc/Release/Functions.html#index-autoloading-functions
Given `~/.zim/modules/foo/functions` is in the `fpath`, autoload looks
for functions in the following files, picking the **newest one** in this
order:
* `~/.zim/modules/foo/functions.zwc`, which should contain all
functions in the directory named `functions`
* `~/.zim/modules/foo/functions/function.zwc`
* `~/.zim/modules/foo/functions/function`
With this approach, we're also having individual entries back in `fpath`
for the `functions` subdirectory of each enabled module (as was the case
before commit 55df5a4).
This is also probably closest to the original plan at #86. The current
code was not compiling "*all* files in a folder into a single digest",
but instead compiling *all* files in *all* the functions folders into a
single digest, which was a bad idea. This commit fixes this.
Fixes#231. Fixes#232. Closes#234.
Closes#239
Since some terminal colour schemes have a too dark blue color that does
not go well with a black background. And since some people actually use
such colour schemes! :- )
Fixes#225
Since some terminal colour schemes have a too dark blue color that does
not go well with a black background. And since some people actually use
such colour schemes! :- )
Fixes#228
They were only being applied to BSD. Also, GNU uses `LS_COLORS`, and BSD
only uses `LSCOLORS`. Keeping these consistent, with same color scheme,
in both GNU and BSD.
Simplify arithmetic command expression without using `${var}`
substitution, but `var` instead. The second construct does not fail if
`var` is not defined, but defaults its value to `0` in that case.
This reverts commit 6022fe46c5.
Current code only works in a GNU with coreutils installed for `ls`, and
only with a `grep` that supports colors (not a Busybox one, for example)
Fixes#230
and refactor code, inlining auxiliary functions inside
`prompt_eriner_main`.
Theme colors are now customizable with parameters. Also, it works better
with light backgrounds by using `%Sstandout%s` for the segments which
were originally using black as foreground color (intended for dark
backgrounds).
The help explains the parameters, and the preview shows one color
variation.
Fixes#169. Closes#226.
The following was introduced in zsh 5.0:
> %F, %K, %f, %k allow colouring of prompts both using ANSI colour names
and values supported by individual terminal emulators.
making this submodule obsolete.
See http://zsh.sourceforge.net/releases.htmlCloses#224
Now that we have a general digest file that can contain all the
functions from all active modules, we can add functions to any of them
without the need to update the `fpath`.
and GNU uses LS_COLORS and GREP_COLORS. So change logic to only set
these environment variables for each OSTYPE.
Also original code was setting the `ls` alias with `-G` instead of
`--color=auto` if in a GNU without `dircolors`. Fix that too.
Simplify arithmetic command expression without using `${var}`, but
`var` instead. The second construct does not fail if `var` is not
defined, but defaults its value to `0` in that case.
Closes#225
and delete the meta module altogether.
Also refactor `tools/zim_issue` to use `tools/zim_info`, use local
variables, and print the output directly without the need of the
intermediate `issue_md` array.
Closes#218
so it's not a template anymore and can be under version control, instead
of being manually updated by the user, as currently is the case with
`~/.zlogin` and `${ZIM_HOME}/templates/zlogin`.
Closes#218
Consider the `zcompdump_file` variable, that could be defined in
`.zimrc`, when cleaning the cache.
A custom zcompdump_file would not be cleaned from the cache without this
correction.
Also remove *.zwc.old files from cache, as zrecompile also generates
these.
Closes#218
for the autoloaded functions. According to the `zshbuiltins`
documentation:
Files containing multiple compiled functions are called `digest'
files, and are intended to be used as elements of the FPATH/fpath
special array.
Compile all module init files, instead of some selected ones.
This didn't impact performance much (time to run async block in zlogin
when from 0.22s to 0.25s on my machine).
Also refactor the zim `init.zsh` script, and do not unset `zmodules`
anymore because we need it in zlogin.
Didn't manage to make adding the prompt `prompt_*_setup` functions to
the digest file work, so kept these separate.
Fixes#86. Closes#218.
in our custom themes.
With zsh starting at version 5.4, when using the `prompt_opts` array,
`nopromptsp` will be set unless the array contains a `sp`. This was
introduced in zsh at
43e55a9bcd (diff-bb10d67e7a8561b66a53a805f3c77a40R233)Fixes#209
While normally it's a good thing that zsh doesn't auto-expand on spaces,
in this case we want to split on spaces into distinct words, that way
the values are passed to `prompt` in multiple params.
Fixes#178
And fix init.zhs to export ZIM_HOME. The zmanage script invokes a new
shell for the sub commands, and those would fail as there would be no
value for ZIM_HOME.
Closes#203
