Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use origin/branch when checking for new commits + python rewrite #16

Open
wants to merge 31 commits into
base: master
Choose a base branch
from

Conversation

thisisrandy
Copy link

This fixes /issues/14 for me (I have coc.nvim checked out from the release branch).

Additionally, there was some other race-condition-like behavior going on where the on_stdout callback was apparently entered variably fewer times than expected (see 72c9dcf for details). I was unable to resolve it in vimscript, but a python rewrite did the trick.

- Check v:vim_did_enter and call for debugging convenience
There was a lot of strange behavior in vimscript version of this plugin.
The on_stdout callback appeared to be called a variable number of times
before the on_exit callback, most likely indicating a race. I tried
refactoring to call the rev-list command sequentially for each plugin in
an async cascade, but for unknown reasons, stdout was blank for about
half of the calls in my setup.

In python, we can use a comparatively simple synchronous function
wrapped in vim.async_call, so that's what I've done. The plugin now
appears to finally work consistently and as expected. Since
async/job.vim is no longer needed, I've removed that as well.
vim.eval returns a string, whereas we need an int for boolean testing
@thisisrandy
Copy link
Author

Oh, I also added a new option g:outdated_plugins_trigger_mode to trigger :PlugUpdate as needed

Was using python2 subprocess.Popen, which accepts the text argument.
Since python3 is utf8, this arg was removed (always returns utf8).
Also got rid of unused stderr var to quiet lint
Got it backwards in the previous commit. subprocess always returns
binary output now, so it must be decoded.

Also used subprocess.run instead of Popen/communicate for simplicity
@semanser
Copy link
Owner

semanser commented Nov 7, 2019

hi @thisisrandy! Thanks for your work and sorry for my late reply.

I've tried it and it works much better than vimscript version. Good job!

What is the minimal version of python required? I want to update the README file.

@semanser
Copy link
Owner

semanser commented Nov 7, 2019

It seems like I'm not able to add commits to this PR (I can't push to master branch on your forked repo).

@thisisrandy
Copy link
Author

Thanks for your reply, @semanser. I've added you as a collaborator on my fork, so you should have push access now. I developed the python bit using 3.6.8, so I know that's safe. Probably should have added the future imports to make it backward compatible, though. I'll take care of that in a bit, or if you beat me to it, you're welcome to do the same.

@thisisrandy
Copy link
Author

Actually, I take that back. The subprocess API changed in python 3, and it seems the run method, which I used, was introduced in 3.5. So 3.5 is the minimum requirement.

Note: this commit should be excluded from any pull requests, but it is
useful for clarity should anyone want to use the fork directly
It's unclear when this broke, but g:plugs[name].branch is apparently
now empty when not explicitly specified. Since this plugin never would
have worked if it was always that way, presumably the behavior changed
at some point
@thisisrandy thisisrandy force-pushed the master branch 3 times, most recently from ca1dc76 to 4c27360 Compare July 25, 2021 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Defect. Plugin shows that there is 1 plugin to update
2 participants