Previously gitgutter could only diff the buffer against the index. This
change enables diffing against the working tree, which will be useful
for stashing.
Use a default with `getbufvar` to not get an empty string.
Fixes:
> Error detected while processing function <SNR>163_on_stderr_nvim[1]..<lambda>10[1]..gitgutter#utility#setbufvar:
> line 1:
> E712: Argument of get() must be a List or Dictionary
I can trigger it using https://github.com/AndrewRadev/linediff.vim when
closing the windows / the tab.
Likely triggered with/through Neomake.
In #303 there was a request to deactivate gitgutter when &diff is set,
although no reason was given initially. Then it was reported that
gitgutter showed signs, in the wrong place, during Fugitive's Gdiff.
However I cannot reproduce signs showing in Gdiff's index buffer. And
the signs in the working tree buffer are correct.
Furthermore the commit which deactivated gitgutter (85f6e136) had the
side-effect of breaking `:redir` and clearing Vim's startup message
(see #500).
Therefore since that change had no benefit, and a couple of drawbacks,
it makes sense to undo it.
Closes#500.
The previous implementation meant the temp file paths were treated as
regular expressions, which was vulnerable to problems with backslashes
etc.
See #494.
This a) logs the message to be seen in `:mess` and b) avoids the
hit-ENTER prompt (which is likely caused by the message not being
logged and Vim deciding that you need to see it then).
So a) fixes b).
An alternative would be to run `git` with no user config always, i.e.
setting `GIT_CONFIG_NOSYSTEM` and `HOME=/dev/null` (different for
Windows then) in its environment. Maybe there's an easier way / single
option for this..
This provides `g:gitgutter_hook_context` during the hook's execution and
removes the `:silent`, but uses `exists()` instead.
The bufnr might be necessary to know in the User autocommand, e.g. to
clear some cache.
Not using`:silent` is good practice in general to not hide (wanted)
output and errors etc.
This is to avoid side effects caused by switching to the buffer to be
written and back again.
It also means that the plugin can process any buffer without having to
make it the current buffer.
Using the lower level writefile() function means we have to deal with
line endings. It might also mean we have to deal with (file) encodings
but I hope not...
See #463, #466.