This was motivated by Vim regaining focus into a buffer with unsaved
changes, and the realtime diff being replaced with an out of date disk
diff. With this commit the realtime diff will be run again.
Use `cd` instead of `popd` because POSIX sh(1) does not have `pushd` and
also because this plugin did not pair its `pushd` with a `popd` anyway.
Use file redirection because POSIX sh(1) does not have anonymous pipes.
If the plugin slows down your Vim too much, you can have it run less
often by setting `g:gitgutter_eager = 0`.
This replaces the former options `g:gitgutter_on_bufenter` and
`g:gitgutter_on_focusgained`.
This problem was revealed when using BufExplorer:
- Open vim with two files: `$ vim a.txt b.txt`
- Type `\\` to open BufExplorer.
- Press <enter> on `b.txt`.
- Vim shows `b.txt` as expected.
- Type `\\` to open BufExplorer.
- Press <enter> on `a.txt`.
- Expected: Vim shows `a.txt`.
Actual Vim shows `a.txt`, `b.txt`, `a.txt`.
I.e. the first invocation was fine but all subsequent invocations
rapidly flicked through <new file>, <old file>, <new file>.
Previously with `gitgutter_sign_column_always = 1` the sign column would
remain after calling `GitGutterDisable`. Now the sign column is always
removed when disabling gutter.
When vim-gitgutter is configured to update on `BufEnter`, which is the
default, we only need to update visible buffers on `FocusGained`.
Other buffers will be updated as and when the user enters them.
When opening Vim without editing any file, calling GitGutterDisable
would fail because `s:file` was undefined at that point. The fix breaks
what encapsulation there is, but has the virtue of working.
The sign column automatically appears when there is at least one sign
and disappears when there are none. There's a small gap between
when vim-gitgutter removes its signs and adds new ones; during that gap
the sign column can flicker.
By adding a dummy sign before removing the real signs, we force the sign
column to remain.
