On Vims that support it, signs are placed in the "gitgutter" group with
a priority set by g:gitgutter_sign_priority.
Closes#544.
Closes#576.
Closes#627.
This removes the g:gitgutter_sign_column_always option.
Vim 7.4.2201 introduced the |signcolumn| option to configure when the
signcolumn is visible, building in behaviour which the plugin provided
manually.
Although it would be good to maintain this feature for older Vims, the
complexity added by the code outweighs the benefit of backward
compatibility.
In fe2b4ec869 (from 2013) the plugin
started using a dummy sign to prevent the sign column briefly
disappearing then reappearing when updating signs.
Since then Vim has vastly improved its handling of signs and the sign
column no longer flickers like this.
The development versions of v0.3.2 also report `has('nvim-0.3.2')` to be
true even if they do not support the `numhl` feature. So here it catches
and ignores the possible errors.
An asynchronous job at startup evidently triggers a Vim (not NeoVim)
rendering bug in some terminals and/or with certain colorschemes.
Terminals reported to be affected: libvte-based ones such as
gnome-terminal, xfce4-terminal, lxterminal, kitty.
Terminals reported to be unaffected: xterm, urxvt.
Closes#619.
For default sign colours.
It seems the Diff* highlight groups are generally designed for line
highlighting so they have background colours which differ from the main
background colour. While desirable for line highlights, this isn't what
we want for the signs.
This change makes the plugin default to using the highlight groups
defined by the colorscheme instead of hardcoding its own foreground
colours.
If you liked the previous colours you can restore them by adding these
lines to your vimrc:
highlight GitGutterAdd guifg=#009900 guibg=<X> ctermfg=2 ctermb=<Y>
highlight GitGutterChange guifg=#bbbb00 guibg=<X> ctermfg=3 ctermb=<Y>
highlight GitGutterDelete guifg=#ff2222 guibg=<X> ctermfg=1 ctermb=<Y>
– where you should replace <X> and <Y> are the background colour of your
SignColumn in the gui and the terminal respectively.
For example, with the solarized colorscheme and a dark background,
guibg=#073642 and ctermbg=0.
Closes#545, #560.
The previous commit switched use of writefile() to binary mode so that
we could prevent a newline being added to a completely empty buffer.
Evidently, however, binary mode has side effects (see #567) so this
commit returns to non-binary mode - with a simpler fix for completely
empty files.
Unfortunately this implementation does not work for noeol files - see
the failing test - because writefile() does not take account of
'nofixeol' (unlike :write). This is suboptimal but acceptable because
noeol files are not be encountered often.
See #567.
An empty, unchanged file was considered to be changed (a new line
added).
This patch fixes s:write_buffer to use binary mode with `writefile` to
not append a newline always, and does so manually for non-empty buffers,
according to &endofline, &binary and &fixendofline.
This is taken out of Neomake, and tested there in
https://github.com/neomake/neomake/blob/091d148b/tests/utils.vader#L713-L759.
Until this commit the err callback closed the channel to prevent the close
callback from being invoked, because the close callback invoked the out
handler (which we don't want when the job was unsuccessful).
This mostly worked but if closing the channel took too long, which it
seemed it could when dealing with large files, the close callback could
be called in the meantime.
This commit removes the unreliable code. The parent commit ensured that
the close callback only calls the out handler when the job succeeded, so
we no longer need to try to prevent the close callback from being
called.
The diffing part of the plugin diffs two files which are written afresh
each time. When the same buffer was processed twice in quick
succession, the second process to write a file could write it before the
first process had finished reading it. This manifested as the "from"
file being read as empty, causing diff to report that all the lines in
the file had been added.
This commit adds a counter to disambiguate successive temporary files.
This prevents git-ls-files from escaping "unusual" characters in
pathnames. When this happened, gitgutter would feed the escaped name
back to git-show but git-show would not recognise it.
This commit makes git-ls-files use the -z option to output pathnames
verbatim. These pathnames also become null terminated so we have to
ensure we remove the null terminator too.
Closes#562.
