11 Jun, 2012
2 commits
-
Plugins that are compatible with both bash and zsh don't obviously have a `.zsh`
extenstion. They use a `.sh` extension. We now support this.Example: rupa/z
-
When running `antigen-update` and there are changes to be pulled, the changed
files are being placed in the current directory, where `antigen-update` is run.
This is because of not setting the `--work-tree` for the `git pull` command.
09 Jun, 2012
3 commits
-
Also renamed antigen-bundle-update to antigen-update for command name
consistency. -
This command lets you bulk-add bundles with one command, and piping bundle
specs, one on each line into this command. Best used with heredoc syntax. -
This is done so that the commands don't clash with other programs. Notably,
Bundler's `bundle` command is a clash.
08 Jun, 2012
13 commits
-
This is so that local repositories can be specified as bundles. This can be
useful if you want to maintain a separate clone for your own plugin when you
experiment and develop stuff and pull in to your environment when you feel
confident. -
Private functions should all be prefixed with `-bundle-`.
-
We can have a performance improvement at shell startup by loading completions in
bundle-apply, only if any of the repositories changed. -
The reasoning behing bundle-apply not being required is that bundle-install is
run everytime the plugin requirements change. But now, without a bundle-install,
bundle-apply finds its place. -
The bundle-cleanup, now cleans up unused clones of repositories, to which no
plugin is referring to. -
This command replaces the old `bundle-install --update` functionality.
-
When a plugin is specified with the `bundle` command, the plugin is immediately
installed and loaded. No need of running a bundle-install and restarting your
shell. -
The `name` argument will be phased out. Instead, the btype will indicate the
type of a plugin. Currently it can have valuse of plugin and theme.
07 Jun, 2012
2 commits
-
It looks like bundle-apply is not required anymore. Now that we call `compinit
-i` at the end of `bundle-install`, we shouldn't need this. Every time a new
bundle is added by the user that defines completions, the `bundle-install` the
user runs, should create the `.zcompdump` with the new completions too. But I'll
keep this here, probably deprecating after some further investigation. -
And a couple of fixes for bugs discovered along the way. These are tests *only*
for the valid syntaxes. Its currently undefined behavior for invalid syntaxes.
Tests for proper error reporting should also be added soon.
06 Jun, 2012
4 commits
-
The previously used two variables ANTIGEN_REPO_CACHE and ANTIGEN_BUNDLE_DIR are
now replaced by a single variable, ADOTDIR. Defaults to `$HOME/.antigen`.
05 Jun, 2012
15 commits
-
The `bundle-list` command is used to list the currently specified bundles.
-
Where there are no bundles, or the bundle directory does not exist, the
`bundle-cleanup` command gives out an error. This fix is to make it give a saner
message instead. -
Current theme and the plugins installed on-spot in current session should not be
listed in the cleanup list. They were because of a problem with updating the
`$bundles` record. This is now fixed.If the above `if` is directly piped to the below `while`, the contents inside
the `if` construct are run in a new subshell, so changes to the `$bundles`
variable are lost after the `if` construct finishes. So, we need the temporary
`$install_bundles` variable. -
This message comes up every time you switch the prompt theme.
-
compinit needs to be loaded at startup too, or the compdef function won't be
defined. -
bundle-init is now renamed to bundle-apply and is to called after all bundle
specifications are given. Also added notes in the README file.The reason is the compinit function needs to be run after adding all the
required directories to `fpath`. The only reliable and performant way to do it
would be to explicitly call a function that does it after specifying all the
bundles. -
The -T is not really required here as we're checking and deleting
the target if it already exists. -
This particular plugin does not provide a completion file with the same name as
the plugin name, but does provide completions for a number of other commands.
So we just add all plugin paths to fpath.See https://github.com/sharat87/lawn/issues/1
04 Jun, 2012
1 commit
-
Instead of making a copy and fixing problems with it (like copying/excluding
.git), we now simply create a soft link to the plugin location.