mhinz / vim-signify

:heavy_plus_sign: Show a diff using Vim its sign column.

---

Signify (or just Sy) uses the sign column to indicate added, modified and removed lines in a file that is managed by a version control system (VCS).

---

• Supports git, mercurial, darcs, bazaar, subversion, cvs, rcs, fossil, accurev, perforce, tfs, yadm.
• Asynchronous execution of VCS tools for Vim 8.0.902+ and Neovim.
• Preserves signs from other plugins.
• Handles nested repositories controlled by different VCS.
• Provides mappings for navigating hunks ("blocks of changed lines").
• Provides an operator that acts on hunks.
• Preview changes in the current line in a popup window.
• Show all changes in diff mode.
• Alternative workflow: Disable the plugin by default and toggle it per buffer on demand.
• Optional line highlighting.
• Optional skipping of filetypes/filenames.
• Optional stats in the statusline.
• Works out of the box, but allows fine-grained configuration.
• Great documentation and handsome maintainers!

---

Similar plugin for git: vim-gitgutter

Installation

The master branch is async-only and thus requires at least Vim 8.0.902. Use the legacy tag for older Vim versions.

Using your favorite plugin manager, e.g. vim-plug:

if has('nvim') || has('patch-8.0.902')
  Plug 'mhinz/vim-signify'
else
  Plug 'mhinz/vim-signify', { 'tag': 'legacy' }
endif

Configuration for async update

" default updatetime 4000ms is not good for async update
set updatetime=100

Demo

Author and Feedback

If you like this plugin, star it! It's a great way of getting feedback. The same goes for reporting issues or feature requests.

Contact: Twitter

Co-maintainer: @jamessan

vim-signify's Issues

Breaks Fugitive's Diff View

Vim-signify seems to break Fugitive's diff view.

Steps to Reproduce

1. Install vim-fugitive
2. Open a file inside a git repo in vim
3. Make a change
4. Run :Gdiff

You should see this error:

Error detected while processing function <SNR>65_start..<SNR>65_diff_get:
line    8:
E344: Can't find directory "fugitive:/test/.git/0/file/here.txt" in cdpath
E472: Command failed

Help File Issue + Feature Request - Vimproc

One small issue I've noticed is that help files seem to lag a bit when I load them up. I assume it has something to do with the size of the file? They aren't contained inside of any sort of repository either. So I suppose 1 question is, could I disable help files from ever attempting to be diff'd?

Second question, would there be any way that Signify could utilize vimproc as a way to prevent any noticeable UI hangups? Ideally it would just use it if installed, and not require it.

Cannot get plugin to work with Vundle

I've tried looking around in the directory and everything seems fine.

The global vim variables are not showing up when i look for them, e.g. let g:signify_difftool yields E121: Undefined variable: g:signify_difftool

In fact, the only tab-completing variables it finds are g:signify_line_highlight and g:signify_sign_overwrite.

So it looks like the plugin is not being loaded in. I am sort of at a loss here because I've been messing around with vim and plugins for nearly 6 months now and this is the first time I've found a plugin that has simply produced no change in behavior.

What's a way to figure out how to debug it? Can someone show me how to set it up with Vundle?

running vim 7.3.874 on OSX and 7.4.31 on Linux (CentOS 6.4)

Update: I was able to figure out a debug routine I could call. It does seem to load up and it even knows about git!

/Users/unphased/.vim/.vimrc
=======================
              active  =  1
               hunks  =  []
              id_top  =  255
               stats  =  [0, 0, 0]
                type  =  'git'

Press ENTER or type command to continue

this file definitely has changes though. How to debug further? Why are there no chunks? What is the cmd line being run to obtain the diff?

Colors not working in iTerm2 with Solarized Dark

Hi there,

I'm seeing about using this over vim-gitgutter as I hope it doesn't slow down console vim as much. However, the default color scheme is gray for add and changed, it is properly red for delete. When I pulled open vim-gitgutter and looked at the highlighting they're using (which does work by the way) it appears they are using the same ctermfg variables that you are (by default) and I tried manually specifying them too but to no avail. See screenshot below:

Thanks,
Jon

The above screenshot is the default vim-signify setup, with no customizations to colors.

The above screenshot is vim-gitgutter "working". The colors are funny because of what you have to do to setup Solarized Dark in iTerm with the color pallet, but I'm used to those colors now at least, and they're better than straight gray.

Let me know if you have any suggestions! Thanks again.

Use shellescape() instead of fnameescape() to escape file names

I had to change fnameescape() to shellescape() to avoid errors when editing files in a path containing spaces in Windows 7.

Something like this needs to be done for all supported VCS types:

let sh_sav = &shellslash
if has('win32')
  set noshellslash
endif
let diff = system('hg diff --nodates -U0 -- '. shellescape(a:path) .' | findstr "^@@ "')
let &shellslash = sh_sav

fnameescape() is meant for arguments to Vim functions or commands, and shellescape() is meant for arguments to external commands. The system() call is the latter.

Problems with spaces in file paths

vim-signify has problems dealing with spaces inside file paths. If I open Vim and edit a file (inside a Git repo) whose path contains spaces, I get the following:

Error detected while processing function 67_start..67_repo_detect..67_repo_get_diff_git:
line 3:
E172: Only one file name allowed: cd /home/rmunn/some/long/path/with some spaces/inside/the/path
Press ENTER or type command to continue
Error detected while processing function 67_start:
line 27:
E714: List required

Error after bwipeout on a dirty file

I'm seeing a strange error when I wipe out the last buffer on a file that is dirty. I can reproduce it every time I open a new instance of vim, then load a dirty file, then do :bwipeout. I get this error:

Error detected while processing function <SNR>29_stop:
line   14:
E713: Cannot use empty key for Dictionary

Removing vim-signify from my bundle folder fixed the problem, but I don't want to do that because I like vim-signify.

Sign column not open when vim starts on editing a VSC tracked modified file

After the following change, it works.

diff --git a/plugin/signify.vim b/plugin/signify.vim
index 02c169d..80b3245 100644
--- a/plugin/signify.vim
+++ b/plugin/signify.vim
@@ -57,7 +57,7 @@ augroup signify
   autocmd!

   autocmd BufRead,BufEnter     * let s:path = resolve(expand('<afile>:p'))
-  autocmd BufRead,BufWritePost * call s:start(s:path)
+  autocmd BufRead,BufEnter,BufWritePost * call s:start(s:path)
   autocmd VimEnter,ColorScheme * call s:colors_set()

   if get(g:, 'signify_update_on_bufenter')

Using signify with multiple buffers in vim

When files are opened in windows so more than one can be seen at once, only the active buffer has the Signify signs enabled on it.

It appears as though I can get it to re-run when switching focus (not by default, though), but it would be pretty nice if we can configure it so that both sets of signs can be seen at once!

Documentation issue with "prev hunk" and "next hunk" mappings

The doc says:

Hardcoded mapping: [c
Configurable mapping: <leader>gn

:SignifyJumpToPrevHunk

Jump to the previous hunk. There are two mappings available:

Hardcoded mapping: ]c
Configurable mapping: <leader>gp

The actual default mappings are <leader>gk and <leader>gj, not <leader>gp and <leader>gn.

Sf should ignore some special buffers

I got this error when I opened a fugitive diff and closed it.

Error detected while processing function <SNR>99_start:
line    2:
E158: Invalid buffer name: fugitive:/Users/zhaocai/Developer/Sh/Project/autodupli/.git/0/scripts/autodupli.in    

Hilight Toggle Error when Default Load Disabled

If signify is disabled from starting by default, with let g:signify_disable_by_default = 1, calling :SignifyToggleHighlight before calling :SignifyToggle produces this error:

Error detected while processing function sy#highlight#line_toggle:
line 6:
E121: Undefined variable: g:signify_line_highlight
E15: Invalid expression: g:signify_line_highlight

The error goes away once :SignifyToggle is called once. Ideally I guess highlight should check to see if signify is disabled for the current buffer, and if it is, enable it.

It may be worth noting that when working with a file with zero modifications, calling highlight will always produce the above error, even after running toggle.

could not figure what's wrong

I installed sy with pathogen and I have this error when trying almost anything

Undefined variable: s:path

What should I do?

Feature brainstorm: highlight character position where edit occurred

I'm somewhat certain that this is possible to do, because Syntastic does it.

In much the same way as the gutter does, but with only text background colors, mark out the positions in the lines where the edits had taken place. For instance, if I add a space into a line the line will become changed and marked with a ! sign, but it would also be super nice if I could see where the edit happened: e.g., a red-background character in the edited line would indicate that the line had content removed from it there, and added characters would be shown in green. It would be nice to be able to attach a number to the red character as well, but that is likely to be difficult.

list index out of range when using `vim-fugutive` to merge confliction with `Gdiff`

when using vim-fugutive to merge confliction with Gdiff

E684: list index out of range: 1
E116: Invalid arguments for function str2nr(tokens[1]), empty(tokens[2]) ? 1 : str2nr(tokens[2]), str2nr(tokens[3]), empty(tokens[4]) ? 1 : str2nr(tokens[4]) ]
E15: Invalid expression: [ str2nr(tokens[1]), empty(tokens[2]) ? 1 : str2nr(tokens[2]), str2nr(tokens[3]), empty(tokens[4]) ? 1 : str2nr(tokens[4]) ]    

CVS support broken?

It appears that signify_enable_cvs is not used anywhere in the sources. Should cvs work atm? It dosn't for me, while git is working just fine. I used the default config and added cvs to the signify_vcs_list.

Persist Signs When Moving Between Splits

I'd love it if the signs would stick around when moving between splits. It's jarring to have the split size change every time I move to a new split.

quickfixsigns was able to accomplish this, but I'm not sure how.

Please allow to specify location of diff tool for SVN

SVN relies on an external tool to get a diff without context.

On many systems GNU diff is available for this.

But it is not always named "diff". For example, on a Solaris machine I recently built Vim on at work, GNU diff is installed as "gnudiff" and there is some other incompatible diff utility installed as "diff".

I'd like an option to tell signify what diff utility to use with the svn diff --diff-cmd call. For now I've hard-coded it.

expose API for changed hunks

i'd like to integrate displaying changed hunks into vim-airline.

vim-gitgutter exposes a function which i can parse to determine +/- of files.

would it be possible to do the same thing here? preferably if it'd easier if it was the same format as i'd only have to parse it once, but if you feel there's a better way that works too.

thanks.

Please use tools installed by default when running in Windows

(Original title: "Make it work in Windows, please")

This is actually really easy for your plugin (unlike http://www.vim.org/scripts/script.php?script_id=1881 which I looked into first).

All you need to do:

1. Use "findstr" instead of "grep --color=never". The search pattern can remain the same.
2. For SVN, use the diff.exe distributed with Vim if "diff" is not executable on the path. I.e. use $VIMRUNTIME\diff.exe, possibly surrounded with quotes or using shellescape(), but beware that using shellescape() on Windows requires you to temporarily unset 'shellslash'.

After setting disabled by default, toggling Signify stops working

If I have let g:signify_disable_by_default = 1 set in the vimrc, subsequent :SignifyToggle or \gt stops working

I'm running on Vim v7.3, and testing on SVN and HG repositories.

BufEnter updates signs too often

Signs don't need updating when BufEnter is triggered due to switching windows or tabs.

For example, gundo switches windows a lot, which causes signify's BufEnter autocmd to trigger unnecessarily every time I navigate between undo tree nodes. This is very annoying because it slows down everything. Switching tabs does the same thing, or switching windows manually (especially annoying when I have two split windows on the same buffer).

For now, I've set g:signify_update_on_bufenter to zero, and tweaked the signify autocmds to also start highlighting on BufRead:

" Init: autocmds {{{1
augroup signify
  autocmd!

  autocmd BufRead,BufEnter     * let s:path = resolve(expand('<afile>:p'))
  autocmd BufRead,BufWritePost * call s:start(s:path)
  autocmd VimEnter,ColorScheme * call s:colors_set()

  if get(g:, 'signify_update_on_bufenter', 1)
    autocmd BufEnter * call s:start(s:path)
  endif

You'll probably want the BufRead change anyway, but there's probably a way to only update on BufEnter when the signs actually need an update as well.

signify_sign_overwrite not behaving as expected.

I have the following in my .vimrc:

let g:signify_sign_overwrite = 0

Unfortunately, this is still replacing signs added by syntastic. I'm not sure if this is a common problem or not.

Update added/modified/removed

It seems that sy is not updating the count after you change a modified file to unmodified, issue discovered in airline:

vim-airline/vim-airline#188

declare scriptencoding to avoid problems

Vim may throw errors when the script is not interpreted as UTF-8 (e.g. on Windows). Adding 'scriptencoding utf-8' at the beginning of the script solves this.

Syntax highlighting lost on lines with signs

Hi,

I would like to configure Sy so that signs appear in the left margin, but without any change to the normal syntax highlighting (the one corresponding to the filetype).

With "let g:signify_line_highlight = 0", the diff highlighting is not visible, but the corresponding lines do not have the normal syntax highlighting either. So in a file with many changes, there is almost no syntax highlighting left, which is quite annoying.

Error message occurs when trying to split.

When I try to do a window split with Vim, the following error occurs:
Error detected while processing function 15_highlight_block:
line 2:
E803: ID not found: 666

performance issue when switching buffers

i used my minivimrc to profile this.

there's a noticeable lag when switching buffers.

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
   14   4.057518   0.001538  sy#start()
   14   4.055980   0.018779  sy#repo#detect()
   14   1.232480   0.006427  sy#repo#get_diff_hg()
   14   0.365108   0.006138  sy#repo#get_diff_svn()
   14   0.345315   0.006035  sy#repo#get_diff_cvs()
   14   0.328554   0.006554  sy#repo#get_diff_git()
   14   0.325205   0.006222  sy#repo#get_diff_perforce()
   14   0.322938   0.006105  sy#repo#get_diff_fossil()
   14   0.317409   0.006991  sy#repo#get_diff_rcs()
   14   0.278700   0.006992  sy#repo#get_diff_darcs()
   14   0.270999   0.006633  sy#repo#get_diff_accurev()

improve windows support

creating this as a placeholder for windows related issues. i thought fixing the path would do the trick but looks like that's not enough.

i just discovered that system('cd foo && git diff') on windows doesn't actually cd into the folder! but since i use startify i never noticed this problem.

secondly, having spaces in the path is problematic because of ' vs ", and so far i haven't found an easy way to extract the dos path (e.g. progra~2/vim) without a ton of code. i think it's almost easier just to force windows users to have diff.exe in their path.

anywho, when i got more time i'll have a look at this, but didn't want you to think i forgot 😉

Signify significantly slows saving a file.

When saving a file with a certain number of changes, slows save by 3-4 seconds.

Profiling:
https://gist.github.com/6619893

Number of signs added by Signify:
https://dl.dropboxusercontent.com/s/vr1le1j07ha8wvz/2013-09-19%20at%201.58%20AM.png

Option to turn off sign columns

I think this looks like a very useful plugin. I am curious if it is possible to turn off the sign columns and to only use the line highlighting. If not, is this a difficult thing to implement. That is, to add an options like g:signify_show_signs.

The reason this feature is interesting to me, is that I want to have my vim window at 80 columns.

Perforce support?

I'm loving the plugin, I was wondering, what would it take to add perforce support?

vim-signify removes linebreaks from '+' register

First of all, thanks for this great plugin.

But because I use set clipboard=unnamedplus, I can't also use vim-signify.

You can replicate the bug even without that setting. In normal mode press "+yy then press "+p a few times to confirm that it is working. Now either run the command :e or :w. Either will trigger some autocommand in vim-signify. After this, pressing "+p will no longer insert the extra line break. After disabling vim-signify I don't see the problem anymore.

does not display on a split screen for 2 buffers

When there is a horizontal split the gutter does not display.

Feature request: Use two digit numbers in removal indicator

IMO, there's not really a need for the indicators to use up the left character for indicating what type it is, this is only really necessary for the most featureless of terminals.

However, there's a way to support two digits for removals (as that is the only marker that needs to indicate a number). Why? Because if you see a number, then it automatically means it is the number of removed lines. The underscore indicator should be implicit!

On a color terminal it would be colored red anyway, to reiterate that it indicates a removal.

Even without using two chars, I would be inclined to assign the number with a non-linear scale on the number of lines removed so that 90% of my changes don't all show up as _> so that it is at least possible to get some vague concept of how many lines were removed. Furthermore there is the a-zA-Z range to dip into on top of the digits for this purpose.

Edit: I see that there is the case for e.g. !1, one line removed after a changed line. Could the convention be changed so that the removal indicator goes on the line below? I don't think that solves the problem of the removal requiring space but with the position actually taking up no space.... hmmm.

]c/[c should move relative to the cursor

Currently, the behavior of the "move by hunk" maps is to jump to the next/previous sign id. This should instead move to the next/previous hunk relative to the cursor.

Sy significantly slowed down my vim when opening files the first time

My vim was very slow. Opening regular files the first time, took about 2 seconds. It took me quite a while to figure ot the cause:

FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
1 1.911840 0.000174 sy#start()
1 1.911471 0.000904 sy#repo#detect()
2 0.440662 0.000075 tagbar#currenttag()
2 0.440501 0.000184 166_Init()
3 0.376236 0.000812 166_ExecuteCtags()
1 0.243657 0.000271 sy#repo#get_diff_bzr()
1 0.243428 0.000240 sy#repo#get_diff_rcs()
1 0.233447 0.000282 sy#repo#get_diff_accurev()
1 0.223392 0.000288 sy#repo#get_diff_darcs()
1 0.223378 0.000288 sy#repo#get_diff_fossil()
1 0.203176 0.000270 sy#repo#get_diff_hg()
1 0.185362 0.000189 166_AutoUpdate()
1 0.185017 0.008813 166_ProcessFile()
1 0.152811 0.000268 sy#repo#get_diff_svn()
1 0.133778 0.000876 166_GetSupportedFiletypes()
1 0.132605 0.000119 GitGutter()
1 0.132568 0.000286 sy#repo#get_diff_cvs()

issue with ]c and [c mapping

it overwrite the vim default. When I do a diffsplit, the [c and ]c key won't work. would you change it to something like [g ]g ?

Disable plugin by default

Plugin work slow for me, and I want disabled plugin by default(BufEnter), and use gt if I want show changes

vim-signify significantly slow down vim in terminal

But for MacVim it works fine.

Signify overwrites syntastic error signs even when set not to

I have "let g:signify_sign_overwrite = 0" in my vimrc (https://github.com/coaxmetal/dotfiles/blob/master/.vimrc) but signify signs still override error signs set by syntastic.

If I trigger a change that creates a syntastic error sign on a line with a signify sign (like an added line), the syntastic sign flashes and is replaced with the signify sign.

CursorHold option only works after first save

I don't know if this is something particular to Vim CursorHold option, but I can make many modifications to a file and none will get automatically saved. Once I save it, CursorHold behavior works just fine.

I can totally live with that, but I would like to know if is anyone experiencing the same?

Signify creates a highlight group named "NONE"

Looks like this is because it calls :sign define with linehl=NONE. (I think it should just be doing linehl= instead, without giving a group name). This is (part of) the root cause of #31 (and godlygeek/csapprox#11) - :CSApproxSnapshot just dumps every highlight group into a new colorscheme file (it doesn't know which groups came from your original colorscheme and which came from other plugins), so this issue leads to the snapshot containing the line

CSAHi NONE term=NONE cterm=NONE ctermbg=bg ctermfg=fg gui=NONE guibg=bg guifg=fg

I'm still working on debugging this further - I'm not clear on why that line is leading to different behaviour than what hi clear None would do - but this is at least part of the problem.

What different you plugin and airblade/vim-gitgutter?

Error "Cannot use empty key for Dictionary" When First Opening a Buffer

When I first open a buffer I get the following error:

Error detected while processing function <SNR>65_stop:
line    5:
E713: Cannot use empty key for Dictionary

This only happens when I start vim and then open a file using :e. If I directly open a file I do not get this error.

Commenting this line fixes the problem:

    "au BufDelete    * call s:stop() | call remove(s:active_buffers, expand('%:p'))

Guessing there just needs to be a 0 buffers check in there somewhere.

]c and [c mappings are backwards from similar Vim commands

Built-in Vim motion commands use ] to go "forward" to the next thing, and [ to go "backward" to the previous thing.

But your ]c command goes to the previous hunk, and your [c command goes to the next. This inconsistency makes the mappings hard to use.

Can you swap the mappings to make them more consistent please?

Highlight differences on a changed line

When the diff highlighting is on, it would be great to see the modified part of a changed line with a special highlighting, just like with a standard vimdiff (or like :Gdiff, in the fugitive plugin). At the moment you know that something has changed, but you don't know what exactly.

Different colors for Change and ChangeDelete

Could you make different colors for Change and ChangeDelete?

I'm moving from gitgutter and I have the same text for Change and ChangeDelete but a different color.

Thanks!

Independent hi groups

As it stands the signs are tied to DiffAdd, DiffChange, DiffDelete, DiffText are there any independent hi groups or an option to flip fg to bg for the sign column?

'SignifyChangeDelete' not working correctly for vim built without netbeans integration

The problem seems to be caused by the fact that vim build with --disable-netbeans won't overwrite previous sign on the same line unless the same id is given.

However, SignifyChangeDelete sign depends on vim to overwrite previous SignifyChange sign to show correctly, see signify.vim line 367:

call s:sign_set(new_line + offset - 1, 'SignifyChangeDelete', a:path)

Tested with terminal vim shipped by Arch linux, signify only shows the SignifyChange sign when theSignifyChangeDelete sign is expetected.

Possible solution is to remove the SignifyChange sign or give the following SignifyChangeDelete a same id.