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.
