mhinz / vim-signify Goto Github PK
View Code? Open in Web Editor NEW:heavy_plus_sign: Show a diff using Vim its sign column.
License: MIT License
:heavy_plus_sign: Show a diff using Vim its sign column.
License: MIT License
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.
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?
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.
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.
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
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?
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.
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.
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.
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
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.
It seems that sy is not updating the count after you change a modified file to unmodified, issue discovered in airline:
I'm loving the plugin, I was wondering, what would it take to add perforce support?
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.
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.
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]) ]
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.
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.
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!
Vim-signify seems to break Fugitive's diff view.
: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
(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:
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.
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()
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!
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.
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 ๐
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?
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')
Plugin work slow for me, and I want disabled plugin by default(BufEnter), and use gt if I want show changes
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.
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
.
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.
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.
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.
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.
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.
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
I installed sy with pathogen and I have this error when trying almost anything
Undefined variable: s:path
What should I do?
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?
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
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.
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.
But for MacVim it works fine.
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.
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 ?
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.
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.
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()
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.