Ken Takata wrote: > Hi Bram, > > 2016/2/25 Thu 5:56:12 UTC+9 Bram Moolenaar wrote: > > Yukihiro Nakadaira wrote: > > > > > > > On Wed, Feb 24, 2016 at 8:11 PM, mattn <mattn...@gmail.com> wrote: > > > > > > > > > > > I'm thinking "kill" is not matter for this test because this test > > > > should > > > > > > be checking of exit. > > > > > > > > > > > > diff --git a/src/testdir/test_channel.vim > > > > b/src/testdir/test_channel.vim > > > > > > index 69922b1..e74e54c 100644 > > > > > > --- a/src/testdir/test_channel.vim > > > > > > +++ b/src/testdir/test_channel.vim > > > > > > @@ -483,6 +483,7 @@ func Test_exit_callback() > > > > > > if has('job') > > > > > > call s:run_server('s:test_exit_callback') > > > > > > > > > > > > + call job_stop(s:exit_job, "kill") > > > > > > " the job may take a little while to exit > > > > > > sleep 50m > > > > > > > > > > > > > > > > In CUI Vim, job_stop(job, "hup") doesn't work because AttachConsole() > > > > fails. > > > > > The following patch might fix it. Job process is created in same > > > > console. > > > > > I'm not sure if it doesn't causes another problem. > > > > > > > > There is a todo item to make it possible to start a terminal for the job > > > > to run in. This is especially useful if the job produces some output > > > > and perhaps even prompts for input. We don't want that to get mixed up > > > > with the Vim display. > > > > > > > > So hopefully we can make both work. This would require the job to be > > > > started with a socket, so its stdin/stdout go to the terminal. > > > > > > > > > > I see. So "kill" is a simple solution. > > > > I'm wondering, if this test fails because the job didn't finish yet, > > don't we have the same problem with every other test, since they all > > start the server? > > Yes, you are right. > When running test_channel.vim on Win32 CUI, many python processes are left. > > > It seems that the default behavior for mch_stop_job() is being too > > gentle. And it only has "kill" and everything else. And that means > > sending CTRL_C_EVENT or CTRL_BREAK_EVENT. > > > > Perhaps we should make the default behave like "kill" and only have > > "hup" and "int" send an event? The default is actually supposed to be > > the same as "term", which for MS-Windows probably is the same as "kill". > > I wrote a patch to change the default to "kill" on Windows. Other > behaviors are not changed. With this patch, no python processes are > left, and of cause the test_channel.vim passes.
Thanks. I'll make the MS-Windows and Unix implementations accept the same arguments, and do what is most similar. For both the default will be "term", which should stop the job normally. For MS-Windows that means killing it, since there is no "gentle" way. -- BEDEVERE: Look! It's the old man from scene 24 - what's he Doing here? ARTHUR: He is the keeper of the Bridge. He asks each traveler five questions ... GALAHAD: Three questions. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.