Add support for Vim-Signify

[hkupty]

As well as gitgutter, add support for vim-signify.

[jreybert]

Thanks for the PR!

But jenkins is positive:

Error detected while processing /home/travis/build/jreybert/vimagit/plugin/magit.vim:
line 74:
E580: :endif without :if: endif

Please fix your commit, preferably with a commit --amend (if error is in last commit) or a rebase --autosquash

[hkupty]

Sorry about that.. It was a bad leftover from previous commit.. Now it should work.

[jreybert]

You save a if statement at runtime, but the evaluation is done at plugin initialization. It means that if vimagit is loaded before gitgutter and/or vim-signify, exists("*gitgutter#process_buffer") will be evaluated to false.

I do not like either the if in the autocmd, but this is the only way to not be dependent on plugin loading order.

Please, only add vim signify support for this PR.

If you find a better way to check gitgutter/vim-signify presence, I'll be happy to merge :)

[hkupty]

Sure.. That makes sense.

I'll cut this down to solving signify for now.

Aside from the if controversy, are you ok with changing the variable name?

[jreybert]

Excellent!

Could you please update the doc/vimagit.txt and README.md with the new g:magit_refresh_gutter and add a note for the deprecated one.

Thanks again for the PR!

[jreybert]

Argh, I missed the jenkins complaint!

Vim(if):E15: Invalid expression: (exists("_gitgutter#process_buffer")) call gitgutter#process_buffer(bufnr(g:magit_last_updated_buffer), 0) elseif (exists("_sy#util#refresh_windows")) call sy#util#refresh_windows() endif

I'll do the doc update, just fix this for the merge.

[hkupty]

Sorry for taking long. This should be fixed now.

[hkupty]

Can we merge this?

[jreybert]

Hi Henry,

I'm very sorry for the delay. I really don't have much time at the moment. It's a pity because you did two nice PRs. You're also the first one to propose PRs touching in the heart of vimagit. That's why I am so careful.

The content of this PR is OK to me. I don't want to discourage you (I really should write some PR guideline). Could you:

• make the pull request on branch next (mandatory)
• reduce the number of commits (nice to have)

For the first point, I want to test your feature one week or two before merging it to master. It is mandatory.

For the second point, it is a nice to have for this commit. It will be mandatory for your next PRs. In a PR, I would prefer to not have:

• add feature foo
• fix feature foo
  Please use git commit --fixup and git rebase --autosquash.

Thanks for your effort!

[hkupty]

No problem!

I'll address those points later this week, as I'm out on holidays.

[hkupty]

@jreybert Done

[jreybert]

Thanks!