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.
