If g:gitgutter_diff_base has been set and the file being processed does
not exist in that branch/commit, ensure that every line is marked as
added - this is how git-diff behaves.
Fixes#855.
E.g., passing an empty group name to the sign argument linehl (e.g.,
"linehl=") causes the following error:
```
Error detected while processing /usr/home/0mp/.vim/plugged/vim-gitgutter/plugin/gitgutter.vim[96]..function gitgutter#highlight#define_signs[10]..<SNR>56_define_sign_line_highlights:
line 9:
E1249: Group name missing for linehl
```
This patch makes the those errors go away by passing "None" when no
group name is needed.
This only applies to floating preview windows on Neovim.
Handles the following way of closing the floating preview:
- <Esc>
- Moving cursor
- 2<C-W>c (where 2 is the floating window's window number)
- <C-W><C-W> to move into and out of the floating window
Closes#786.
This bug was introduced by 9784226 in #708. It had the effect of not
allowing an existing hunk preview window to increase in size for a
larger hunk (up to 'previewheight').
See #775.
I would prefer to remove the statusline altogether in the hunk preview
window, making it consistent with the floating preview window. However
I do not think that is possible; the best one can do is make it blank.
Vim does not check the existence of its temp directory when generating
file names with tempname(). Therefore if, for some reason, the temp
directory gets deleted, Vim will continue to generate paths for file
names inside the directory. Writes to these file paths will fail
(E482).
See #746, #433, #190, #147.
This reverts "Use fresh temp files for every diff" [1]. At the time I
did not realise that Vim never checks the existence of its temp
directory after creating it at startup; I thought that each call to
tempname() generated a fresh file on disk. In fact tempname() simply
generates a string path.
Therefore there is no point calling tempname() for every diff. Doing so
only serves to generate more files in the temp directory than necessary.
[1] dab840b153
Setting a colorscheme often clears all existing highlight groups. When
the plugin subsequently sets up its colours, it sees that the GitGutter*
groups exist and leaves them alone - even though they have been cleared.
This change means cleared groups do get their colours set up again.
See #727.
