overrides may now be specified for any of these defaults:
TODO_DIR=$BASH_IT/custom # change if you want todo.txt and friends
# to live somewhere else
TODOTXT_DEFAULT_ACTION=ls # change if you want a different action,
# like 'lsp' or 'lsprj'
TODO_SRC_DIR=
$BASH_IT/plugins/available/todo # for custom installs with plugins
Since it is referenced in the default .bash_profile and in aliases and
themes, why not make it an official plugin?
This creates a 'todo/' directory in /plugins/available, and installs
todo.sh and friends there. Tab completion and the 't' alias should work
out of the box.
Note: it was also necessary to modify .gitignore to ignore the files
todo.sh generates in custom/.
cite about-plugin metadata. This could be retrieved later, say by an
install script or other helper function, with:
cat ~/.bash_it/plugins/enabled/base.plugin.bash | metafor about-plugin
In this way, summaries of each plugin may be provided to give newcomers
(like me!) an overview.
also, rewrote plugins-help(), which didn't work very well on my system.
It now dynamically queries composure metadata.
The [fasd](https://github.com/clvv/fasd) project replaces the current
z() functionality, and generalizes it for all files and directories.
It provides a 'z' alias which works like z() does today, but faster, as
well as 'f' for selecting files, and 'd' for selecting directories, all
based on 'frecency' with Bayesian inference calculations. It is also
trivial to set up a 'v' alias to edit frecently used files.
Seriously, two points just for using Bayes' theorem.
I've sourced this as a plugin, and made a minor modification to @clvv's
0.5.4 file to bootstrap the initialization process without installing
fasd outside of Bash_it, or modifying the PATH.
This doesn't fully install fasd on a system (for instance, the man page
is not installed).
Using this as a plugin will clobber the z plugin.
This also installs a PROMPT_COMMAND hook. I don't have a complex setup,
but it is possible this may not play nice with other PROMPT_COMMAND
hooks if they are set. It seems to work well on my box.
As an aside, it appears that z.bash is out-of-date compared with @rupa's
latest code.
This allows users to disable a plugin without completely removing it.
Instead, they simply remove the `plugins/enabled/*.bash` file for the
plugin they want to disable. This continues the concept of "everything
on" while providing greater flexibility to future users.
It might be a good idea to allow turning these off by default in the
future and allowing not only the `plugins/enabled/*.bash` files but also
an array of `<plugin_name>` values that would search for
`plugins/available/<plugin_name>.plugin.bash` to enable them. That
method would make it easier for people custom tune their plugins from
within their `.bash_profile` script.
Erich Smith
Nils Winkler
Travis Swicegood
Mike Thornton
Eitan Adler
Antono Vasiljev
Robert Evans
Victor Castell
Mark Szymanski
Yakkala Yagnesh Raghava
Antono Vasiljev
David DeSandro
JFSIII