Pass the git command to `jobstart()` as a string, not a list.
`jobstart()` does some kind of internal black magic to parse strings
like `'"/usr/bin/env bash" -l'`, whereas it would be impossible to pass
in an equivalent argument using a list.
Before, the value of `&shell` was being passed verbatim to `jobstart`
because no word splitting is done when the argument to `jobstart` is a
list. This would cause errors if the user's `&shell` were set to
something like `'/usr/local/bin/zsh -l'`.
This does not, however, fix another potential edge case, when the shell
command itself requires quoting (as per the example in the Neovim docs,
option E91). After doing some testing, it appears that `jobstart()` cannot
handle a quoted command, despite the recommendation in the manual (and
despite the fact that commands like `:terminal` work just fine with
double-quoted values for `&shell`). Whether this inconsistency is due to
a bug or something else, additional defensive action is probably needed.
For demonstration, try symlinking `/bin/bash` to `"./bad shell"`, and
inside Neovim setting `let &shell='"./bad shell"'. Everything works
fine, except `:call jobstart([&shell])` fails. Try various combinations
of quoting and calls to `jobstart()`, `split()`, and such: there seems
to be no way to get `jobstart()` to handle the quotes and spaces
properly without additional manipulation up-front.
Before this change, neovim's omnicompletion would always insert the
first completion option without allowing the user to choose any other.
Thanks to @lvht, @chemzqm, and @Shougo for help with this.
Closes#310, #311.
Reverts feature introduced in commit d59ac0394a
If you know your system's grep command does not support color, please use:
let g:gitgutter_grep_command = 'grep -e'
Reverts feature introduced in 5c23cadf57
In order to use an escaped grep, please replace
`g:gitgutter_escape_grep=1` with:
let g:gitgutter_grep_command = '\grep --color=never -e'
This change breaks up the determining of the user's grep command, and
the arguments it sends it.
Configuration is now:
let g:gitgutter_grep_command = 'grep --color=never -e'
This makes it easier for users to configure now, though not quite as
flexible.
Instead of creating two new temporary files every time a realtime diff is
performed, reuse the same two temporary files (per file extension).
This stops the plugin using hundreds of different temporary files.
Since the plugin now only uses a handful of temporary files we do not
need to wipeout the unlisted buffer created by vim for each index-blob's
temporary file.
In turn this means vim no longer needs hundreds of unlisted buffers, so
the next-available-buffer-number stays at sensible levels.
See #297.
The buffers being wiped out are temporary ones used to hold the contents
of a "real", unsaved buffer. Ideally vim wouldn't create them at all;
and in fact it seems sometimes vim does not create them (#258).
It would be good to find why the buffers are usually there but sometimes
not. In the meantime this change works around the problem.
This makes so that editing helpfiles directly triggers the gutters,
while keeping the default behaviour of editing help buffers (opened
with `:help stuff`) doesn't.
The `&&` and the `||` operators aren't available in fish.
The equivalents are `; and` and `; or`.
Also single parentheses are used for command substitution.
The fish equivalents are `begin` and `end`.
But they aren't needed here.
Most colorschemes (e.g. solarized) don't give any thought to the
SignColumn highlight group so generally the sign column is ugly.
With this change vim-gitgutter defaults to making the sign column look
like the line number column.
Solarized users no longer need `highlight clear SignColumn` in their
vimrc :)
To stop vim-gitgutter from overriding the SignColumn highlight, add this
to your vimrc:
let g:gitgutter_override_sign_column_highlight = 0
Not all versions of grep support the --color flag. This checks the
output of grep --help when building the grep command and avoids using
flags that aren't compatible with the version present.
Fixes#234.
`git diff` doesn't perform EOL conversion on stdin, causing it to
mistakenly flag every line as having changed when the working tree uses
a different EOL than the blobs. Writing the buffer to a temporary file
and diffing against that avoids this issue.
Fixes#232.
