“p4 monitor info” isn't always available and can impose a heavy runtime
cost when it is if the server isn't responsive.
Closesmhinz/vim-signify#153
Signed-off-by: James McCoy <vega.james@gmail.com>
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>
This handles the case where a user forces colors from the color extension via
hgrc:
[extensions]
color =
[defaults]
diff = --colors=always
Sy disables these for its 'hg diff' call, otherwise the output would be
riddled with color escape sequences and couldn't be parsed properly which
would result in no signs shown.
References #146.
Mercurial's detection for where a file's containing repo is doesn't work
well when the working directory is a different Mercurial repo (c.f.,
mhinz/vim-signify#146). Run "hg diff" from the target file's parent
directory to work around this.
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.
`:SyDebug` is displaying info if an alternate buffer is set. This
occurs because a buffer number of 0 represents the alternate buffer.
Using a 1-based range in sy#debug#list_active_buffers fixes this.
Signed-off-by: James McCoy <vega.james@gmail.com>
References #97.
Prior to this patch, it was not possible to dynamically apply arguments
to diff commands. The g:signify_diffoptions variable was only read when
the plugin was loaded.
This patch changes the behavior so that before each diff it checks
g:signify_diffoptions to see what arguments should be passed to the diff
tool.
The motivating use case behind this change is to be able to diff against
a different branch in Git via a key mapping. However, This change will
also allow any other arbitrary diff options to be dynamically updated,
such as whitespace, etc.
Example: Show diff against master instead of against HEAD in Git
nnoremap \u :let g:signify_diffoptions = { 'git': 'master'}<CR>:SignifyToggle<CR>
Prior to this patch a VCS was only detected by checking if a potential
diff was empty or not. Now the combination of return value and diff is
checked, so it detects an underlying VCS properly even when there are no
changes.
This can save many useless calls to the wrong version control systems.
Simple test:
- open a version-controlled file without any changes
- :SyDebug should show the correct VCS now (instead of 'unknown')
Closes#82.
After one of the recent changes 'deleted' was used in a place where
'removed' should have been used. This could lead errors:
Error detected while processing function
sy#toggle..sy#start..sy#repo#process_diff..sy#sign#set:
line 10:
E155: Unknown sign: SignifyChangeDelete12
ANSI escape sequences in a patch would confuse Sy. People are advised to
set their color settings to 'auto' instead of 'always', so color codes
would only be used if the output is meant for the terminal.
Thus we just ignore color.diff settings now.
References #72.
The [default] argument is used for setting the default highlighting for a group. If highlighting has already been specified for the group the command will be ignored. Also when there is an existing link.
This patch makes jumps go the the first/last hunk when the given count
was bigger than the available hunks.
E.g. when there are only 2 hunks and you use 4]c, the cursor jumps to
the last hunk nevertheless. Before this patch the cursor wouldn't move
at all (which mimics the standard behaviour of ]c/[c).
Closes#41.
