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 job for s:system() on vim8 #594

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

Conversation

mattn
Copy link
Contributor

@mattn mattn commented Feb 15, 2017

Vim dispose jobs in main thread. So vim stop job operations while calling system(). This use job in s:system().

Left is without this patch. Right is with this patch.

terminal

@junegunn
Copy link
Owner

Thanks, it looks interesting. But there are places we refer to v:shell_error after s:system call to see if the call was successful but job_start, understandably, doesn't update the value. And I believe that's the reason the test cases are failing.

e.g. :call system('xxx') | PlugUpdate.

Also I wonder why bumping up maxfuncdepth is necessary. I can confirm that if it's not increased Vim gives errors when running :PlugUpdate99, but I still don't see why Vim complains when there are no recursive calls.

@mattn
Copy link
Contributor Author

mattn commented Feb 16, 2017

I will add code for v:shell_error. About maxfuncdepth, job_status catch-up another running jobs. So when another job make the error, exception will be raised at the line at job_status. The effect of this change, muliple jobs can be spawned in same time. So we need to grow-up maxfuncdepth.

@junegunn
Copy link
Owner

I think we should stop using v:shell_error. We can make s:system() return [result, error] pair.

@mattn
Copy link
Contributor Author

mattn commented Feb 17, 2017

yes, we have better to separate s:system and s:systm_with_error? as far as i see, s:system is used in many part like let foo = s:some_func(s:system(cmd)).

@mattn
Copy link
Contributor Author

mattn commented Feb 21, 2017

added s:system_with_error which return two values.

@@ -1979,34 +1982,70 @@ endfunction

function! s:system(cmd, ...)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s:system can be simplified to s:system_with_error(...)[0].

plug.vim Outdated
\ a:spec.branch), a:spec.dir)), '\t')
if !v:shell_error && ahead
\ a:spec.branch), a:spec.dir)
let [ahead, behind] = split(s:lastline(output), '\t')
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this can fail if output does not have \t because of an error, right? It was my oversight.

plug.vim Outdated
@@ -1053,14 +1053,16 @@ function! s:update_finish()
if !pos
continue
endif
let shellerror = 0
if has_key(spec, 'commit')
call s:log4(name, 'Checking out '.spec.commit)
let out = s:checkout(spec)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s:checkout can fail. It used to set v:shell_error which is tested at line 1079, but now we have to update shellerror. The same goes for line 1072 and 1076.

plug.vim Outdated
\ a:spec.branch), a:spec.dir)
let [ahead; behind] = split(s:lastline(output), '\t')
if !shellerror && ahead
if len(behind) > 0
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

behind is a list, so line 2060 should be updated accordingly.

Copy link
Contributor Author

@mattn mattn Feb 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want the behind is joined with " " ?

Copy link
Owner

@junegunn junegunn Feb 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original code expected exactly two numbers, which is a correct assumption given that git rev-list --count --left-right HEAD...origin/master works as expected. I think behind[0] should suffice. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your's is best. will fix soon.

Copy link
Owner

@junegunn junegunn Feb 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should test len(behind) == 1 instead?

EDIT: 1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

@mattn mattn force-pushed the use-job-system branch 2 times, most recently from b3e794b to 352cc75 Compare February 22, 2017 04:02
plug.vim Outdated
if !shellerror && ahead
if behind
if len(behind) == 1
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, sorry, one more thing, I think we should change these lines to

if !shellerror && ahead && len(behind) == 1
  if behind[0]

plug.vim Outdated
if !shellerror && ahead
if behind
if !shellerror && ahead && len(behind) == 1
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry if I wasn't being clear. What I meant is to change line 2054 and 2055 as follows:

if !shellerror && ahead && len(behind) == 1
  if behind[0]
  1. First if statement checks if the output of the command conforms to the expected format
  2. Second if statement checks if behind[0] is a non-zero value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No prob

@junegunn
Copy link
Owner

junegunn commented Feb 22, 2017

A few test cases are still failing on Vim 8:

https://s3.amazonaws.com/archive.travis-ci.org/jobs/204097914/log.txt

Looks like the lines in the output of the new system function are not properly separated by newline characters ( ... new_branch_nameHEAD is now at ...), any idea?

(109/134) [EXECUTE] Commit hash support
> ['Updated. Elapsed time: 0.256267 sec.', '[=x]', '', '- Finishing ... Done!', 'x goyo.vim:', ' error: pathspec ''ffffffff'' did not match any file(s) known to git.', '- vim-emoji: Note: checking out ''9db7fcfee0d90dafdbcb7a32090c0a9085eb054a''.You are in ''detached HEAD'' state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.If you want to create a new branch to retain commits you create, you maydo so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_nameHEAD is now at 9db7fcf... MIT license (close #2)']

@mattn
Copy link
Contributor Author

mattn commented Feb 22, 2017

Sorry, It's difficult to read the test result for me.

@junegunn
Copy link
Owner

junegunn commented Feb 23, 2017

I'll look into those errors when I get some time. By the way, I tested the patched version on my machine.

  1. I can notice the difference when I do PlugUpdate99 that Vim becomes responsive earlier, I can move the cursor before every plugin is queued. However, the total time for the command is more or less the same; 8~10 seconds for 62 plugins with or without the patch. Maybe the difference is more noticeable on Windows?

  2. A subtle issue I noticed is that when Vim becomes responsive, my cursor ends up on a random line. Before the patch, it's always on line 2.

screen shot 2017-02-23 at 11 07 58 pm

screen shot 2017-02-23 at 11 07 50 pm

  1. For testing/debugging the issue I mentioned above, I tried commenting out redraw line. Then I noticed that some random errors occur during the update as shown below.

screen shot 2017-02-23 at 11 07 07 pm

screen shot 2017-02-23 at 11 07 24 pm

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.

None yet

2 participants