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.
Highlight groups for signs:
- renamed highlight groups with `GitGutter` prefix, and following the
naming style of the builtin groups `DiffAdd`, `DiffChange`, etc.
- using `highlight default link` to set default colours for signs.
e.g. the plugin defines `GitGutterAddDefault` as green, and default
(if `g:gitgutter_highlights`) links `GitGutterAdd` to it (which the
user can customise).
Highlight groups for lines:
- added gitgutter-specific highlight groups for line highlighting
(`GitGutterAddLine`, etc) so that this highlighting can be customised
independent of `DiffAdd` et al (which these default link to).
- line highlighting toggling now only changes the linehl attribute.
The `linehl` attribute is toggled in `s:update_line_highlights`,
which separates concerns more clearly. I'm thinking ahead to the
possibility of the sign text being configurable, and thinking it will
be DRYer to keep these things separate. Maybe it's just aesthetic
though.
Bonus: resolved "eugh" ;)
This updates the signs on the current file when you return to GUI vim.
For example, you make some changes in Vim, tab to your shell and commit
them, then tab back to Vim; at this point you want the signs to update
automatically for you.
This fixes a bug whereby opening Vim on a non-git tracked file, then
calling `:DisableGitGutter` or `:ToggleGitGutter`, tried to clear a
variable before it had been defined.
Some people have reported a failure whereby at least one `line` in the
diff results doesn't match the hunk regexp. I believe, though cannot
say with certainty, that this is due to mismatching newline shenanigans.
However this theory doesn't explain how the failure could occur on a
file without changes, as reported by one person. Furthermore I think
that the hunk results would have to have double \n characters to cause
this failure, which I don't think would ordinarily occur on Windows or
Unix.
Whatever the reason, this change copes with the situation.
