Hardly needed to do repeatedly and when it is, it's best linked with
an observed command on the same line.

I keeo forgetting to say "modify" and even `m` alias did not help.  This
maybe...

This used to be re-set in host-specific bashrc, but we already rely on
so many things installed anyway...

This reverts commit 55a4088d807c5ca0552e89c3240ec1d3c88842f6.

Turns out this makes it too hard to explore and learn the vast potentials
of taskwarrior CLI.

Since task IDs are dynamic in taskwarrior, commands like `task 4 delete`
and `task 4 done` can be destructive with hard-to-trace damage if
inadverently repeated.

Better to avoid that, even at cost of not remembering anything.

(Note that `task` without arguments is still remembered; there's no harm
in repeating that, and it still can be convenient eg. w/ ^L).

http://unix.stackexchange.com/a/18443/9365

Using grep directly could result in "binary file matches" without any
useful info.

This would happen e.g. after renaming some files with badly-encoded
filenames.  Bash history builtin seems to address such cases better.

These variables only make sense in interactive bash session where we
always re-read .bashrc anyway.

Mostly due to ls...

Turns out that these need to be often repeated

At least on Fedora this is tmpfs