This reverts commit 6ab96c13937754e3078076c7fb6996a404f04459.
Unfortunately the situation is a tad more complicated than I thought. Revert for
now and have an eye on https://fossil-scm.org/forum/forumpost/834ce0f1e1
Assuming line 28 was deleted, the block header for a unified diff looks like:
+28,1 -27,0
This is true for usual suspects like `diff -U0` and `git diff -U0`, but
unfortunately not for Fossil. It would report this instead:
+28,1 -0,0
This lead our code to believe that line 1 instead of line 28 was deleted. And
maybe it's right about that. There does not seem to be a standard for patch/diff
output, but according to my knowledge Fossil is the only VCS doing that.
Anyway, this commit's change should make the detection of a deleted first line
work for every VCS again.
Fixes https://github.com/mhinz/vim-signify/issues/282
Assume a hg repo below a git repo. `git diff` on a file managed by hg, will
return a successful exit value, but no output.
So, if we got a successful exit value from multiple VCS tools, and none of them
gave any output, keep them all as potential candidates. The next time Sy is run,
only these candidates will be tested again.
If one of them returns a proper diff, set b:sy.updated_by to that VCS and prune
all other candidates.
References #235
This is only enforced for dynamically created signs, namely
g:signify_sign_delete and g:signify_sign_changedelete, if
g:signify_sign_show_count is on.
References https://github.com/mhinz/vim-signify/issues/105
Having default values for options that depend on another option's value is a bad
practice. Be more explicit:
g:signify_sign_show_text is ON by default
g:signify_sign_show_count is ON by default
So, people who want just background colors and no text at all in their signs
have to set both:
let g:signify_sign_show_text = 0
let g:signify_sign_show_count = 0
Before this change, only the first line was needed.
This also fixes a bug that happened with:
let g:signify_sign_show_text = 0
let g:signify_sign_show_count = 1
Removed lines wouldn't show a count whereas changed + removed lines would.
When you have nested repos of different VCS and you edit a file from the inner
repo, more than one VCS can return a valid diff. Only one VCS should return a
non-empty diff, though.
Once a non-empty diff is found, all other VCS get disabled to reduce overhead.
References #235.
Since we don't switch the window anymore, we can't simply refer to b:sy as we
used to do while Sy worked only synchronously.
Now we provide the buffer number to each job and the exit handler gets a pointer
to the b:sy of that buffer and passes it to all the subsequent functions.
References #209, #210.
This makes all Signify signs use a non-breaking space as text. This is
convenient if only the background colors of the signs are important.
References #188.
sy#stop() is called by the BufDelete autocmd so b: variables may not
correspond to the buffer actually being deleted. Instead, we must use
<abuf> to determine which buffer is being deleted and pass that into
sy#stop().
There are some ripple effects, causing sy#sign#remove_all_signs to also
gain a buffer number argument.
Signed-off-by: James McCoy <vega.james@gmail.com>
I wanted to be able to customize signify in a way that wasn't possible
with the current set of options. This commit adds 2 new options and 2
new highlight groups.
Specifically, we can now
1. differentiate between changes, deletes AND signs that have both
with the `signify_sign_changedelete` option.
2. disable showing the number of deleted lines in the sign column with
the `signify_sign_delete_use_count` option.
3. highlight lines with changes and deletes specifically with the
`SignifySignChangeDelete` highlight group.
4. highlight the first line differently with the
`SignifySignDeleteFirstLine` highlight group.
All of these default to existing settings/highlight groups, so
everything should continue working the way it does now.
--------------------------------------------------------------------------------
For those that are curious, I wanted to configure signify to show no
symbols in the sign column, and to just use the highlight groups to give
me all the information I needed. I am able to achieve that now with the
following settings and the Solarized colorscheme:
let g:signify_sign_add = "\<Char-0xa0>\<Char-0xa0>"
let g:signify_sign_change = "\<Char-0xa0>\<Char-0xa0>"
let g:signify_sign_changedelete = "__"
let g:signify_sign_delete = "__"
let g:signify_sign_delete_first_line = "‾‾"
let g:signify_sign_delete_use_count = 0
hi SignifySignDelete term=bold,underline cterm=bold,underline ctermfg=1 ctermbg=12
hi SignifySignDeleteFirstLine ctermfg=1 ctermbg=12
hi SignifySignChangeDelete term=bold,underline cterm=bold,underline ctermfg=1 ctermbg=3
You can see it in action here:
https://twitter.com/_bentomas/status/486266117204090880
On the Chinese version of Windows, v:lang is "zh_CN", but execute
":language zh_CN" will fail and ":language chinese_china" must be used
to change the locale instead.
Closes#116.
If there are more than 99 deleted lines, the actual count isn't being
important anymore. Thus we just let it overflow and save another
conditional.
100 deleted lines -> "00"
Closes#109.
This bug happened when a unicode character was used for the delete sign.
Prior to this patch we used string subscripting which worked fine for
ASCII characters, but see yourself:
:echo '«5'[-2:]
Defining the SignifyDelete set of signs on the fly provides the ability
to specify the exact line deletion count for up to 99 lines, rather than
the current limit of 9 lines.
This also has the benefit of reducing the number of signs defined when
there aren't many hunks of deleted lines. On the flip side, if there
are other sign-placing plugins in use, then it also increases the chance
of nearing the ~120 sign definition limit if there are many hunks of
varying line deletions.
