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

MacVim GUI does not report job_start() failure when executable does not exist #322

Closed
neowit opened this issue Aug 14, 2016 · 8 comments · Fixed by #326
Closed

MacVim GUI does not report job_start() failure when executable does not exist #322

neowit opened this issue Aug 14, 2016 · 8 comments · Fixed by #326

Comments

@neowit
Copy link

neowit commented Aug 14, 2016

if job_start is called with an executable which does not exist then console version of macvim reports failure in callback function, while GUI does not.

Tested in MacVim from homebrew, exact version details see below.

Consider following demo.vim

" job start failure is reported in terminal, but not in GUI mode

function! MyCallback(...)
    " a:1 - channel, a:2 - message
    let l:msg = a:0 > 1 ? a:2 : ""

    echomsg l:msg
endfunction

function! JOB_START()
    let command = "aFakeCommand"

    let job = job_start(command, {"callback": function("MyCallback")})
endfunction    

First try console version of macvim
$ vim -u NONE -U NONE -N -S demo.vim

:version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 11 2016 19:06:30)
MacOS X (unix) version
Included patches: 1-2196
Compiled by Homebrew
Huge version without GUI.

:call JOB_START()

result:

executing job failed: Not a directory

Not the clearest message, but at least a hint of something wrong with the command.

Now run the same scenario in GUI
$ mvim -u NONE -U NONE -N -S demo.vim

:version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 11 2016 06:29:47)
MacOS X (unix) version
Included patches: 1-2196
Compiled by Homebrew
Huge version with MacVim GUI.

:call JOB_START()

result: nothing reported in :messages, job fails silently.
I did few tests and it looks like "callback" is not being called at all.

In case if anyone interested - my use-case is a vim plugin and works as follows:

  1. job_start() starts a server (java program)
  2. ch_open and ch_sendraw() are used to communicate with the server

If job_start() fails silently then there is no way for the end user to figure out why their action is not being executed.

@splhack
Copy link
Contributor

splhack commented Aug 17, 2016

No failure in this test https://github.com/macvim-dev/macvim/blob/46c4d4ac66aa2b129f4dcec9debfda606f72d4b3/src/testdir/test_job_fails.vim even though on GUI mode. I don't know callback should be called or not in this case.

@neowit
Copy link
Author

neowit commented Aug 17, 2016

Hello @splhack

Thank you your feedback.

My main reason for opening this issue was to point out an inconsistency.
Normal vim and console macvim both invoke the callback on job failure, and it is only GUI mode of MacVim does not call the callback, hence my assumption that in GUI mode macvim does not behave correctly in this sort of situation.

@splhack
Copy link
Contributor

splhack commented Aug 20, 2016

#330

@splhack
Copy link
Contributor

splhack commented Oct 3, 2016

@splhack
Copy link
Contributor

splhack commented Oct 5, 2016

@neowit
Copy link
Author

neowit commented Oct 6, 2016

Hello @splhack

Unfortunately I am not familiar with vim build/patch process (I just write vim plugins) and not sure how to test that diff. Is there an instruction which explains this process?

@splhack
Copy link
Contributor

splhack commented Oct 9, 2016

dc0ccae

@splhack splhack closed this as completed Oct 9, 2016
@neowit
Copy link
Author

neowit commented Oct 17, 2016

hello @splhack

Just wanted to confirm that current version of macvim (8.0 includes patches: 1-32 ) handles job start failure as expected.
Thank you for merging the fix.

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 a pull request may close this issue.

2 participants