Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Run GitGutter when re-entering split window. #46

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants

uxp commented Mar 8, 2013

Nearly identical to b6c5364, update the signs on the buffer when
re-entering the split window. This is probably only used in addition to
other Git related vim plugins, like vim-fugitive by @tpope, when used
inside the same terminal session. :Gcommit opens a new split window to
enter the message, and afterwards switches back to the window previously
in focus. This should automatically update the signs then.

Expand: b6c5364 Run GitGutter when re-entering split window.
Nearly identical to b6c5364, update the signs on the buffer when
re-entering the split window. This is probably only used in addition to
other Git related vim plugins, like vim-fugitive by @tpope, when used
inside the same terminal session. :Gcommit opens a new split window to
enter the message, and afterwards switches back to the window previously
in focus. This should automatically update the signs then.

xer0x commented Mar 9, 2013

+1 I was about to make a new issue because I thought the vim-gitgutter didn't support splits. However, I just needed to force it to update again. Automatically having the plugin refresh would be really great.

uxp commented Mar 9, 2013

I typically run Vim split into two with my tests in one and my code in the other (and tmux split between vim and my test runner, but that's irrelevant here). As the plugin stands in master, switching between splits and switching between the tmux shell and vim all will not reload the signs.

I've been running my addition all day, and I personally like the improvement, but there might be an argument to be made for reloading the signs when leaving a split window (into the other window) as well. The length of arguments on which I've added my addition to call :GitGutter gives me worry, and I don't feel comfortable tacking on a half dozen more events in the case those might be useful to others. I also would want the number of calls to :GitGutter to be fairly conservative for performance, though that might be premature.

Either way, I think a bit of discussion should be focused around this to see where a good balance of reloading calls could be placed for the multitude of ways Vim users would like their gutters refreshed before this gets blindly merged in.

Owner

airblade commented Mar 12, 2013

I think this is a trade-off between accuracy and speed. Ideally we want vim-gitgutter to update at every opportunity but in practice this can slow down the GUI (see #5).

Did you notice any slowdown in your Vim using WinEnter?

Also I wonder what are the other events that you've added?

I'm not sure whether there's a definitive answer for which events to use. I could add a note to the README drawing attention to this, and show how people could add extra events in their vimrc.

But at the end of the day many people use vim-fugitive and it would be great to work well with splits out of the box...

uxp commented Mar 13, 2013

After using it for the past few days I can say that I definitely see slowdown when using WinEnter. It's not enough for me to get mad about, but it is noticeable. What is your initial goal with the plugin's performance? Personally, I probably would avoid additions that have noticeable performance issues.

So far I haven't added any other events. Like I said, it would be awesome if every event was on that list so the gutter would update seemingly in real-time, but like you said, this is absolutely a trade-off between accuracy and speed.

I agree, pointing this out in the README is probably a needed addition. It might be worthwhile looking into adding a configuration option that overrides the defaults as well (editing libraries and plugins always feel dirty to me, but I'm weird). There are just too many plugins people will use alongside this, and too many configurations, window preferences and editing preferences outside of Vim to be able to cover all the different ways people will want their Signs updated.

I'd be happy to help add a section in the README discussing the performance implications and how to override the events list in a new PR if you would like. Feel free to close this without merging if it's not something you want to add.

Owner

airblade commented Mar 15, 2013

As of 677dac4 this is on by default, though you can opt out if you like.

@airblade airblade closed this Mar 15, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment