handle other outputs on pt eventloop

[minrk]

Now that we use prompt-toolkit, we have an eventloop we should be able to use to check for outputs coming from other frontends without waiting for the user to hit enter and request a new prompt. However, the situation right now is actually worse than readline, because we currently don't check for incoming output until execution, instead of on every prompt. Plus, there appears to be something about assumption of newlines that has gone awry, because this is what it looks like now:

In [1]:

In [1]: 1
Out[2]: [remote] In [1]: a=1[remote] In [2]: a[remote] 1
Out[3]: 1

cf https://github.com/jupyter/jupyter_client/pull/185#issuecomment-245633331

[takluyver]

It should be easy to avoid it clashing with the prompt, by using PT's patch_stdout_context() context manager. Integrating with the event loop may take a bit more effort, but should also be possible.

[ivan-krukov]

Would it be appropriate to have an extra thread that monitors iopub messages?

[ivan-krukov]

If that would be an appropriate resolution, then I can create a PR.

However, I am having little luck with patch_stdout_context here. With the context manager in place, the prompt behaves correctly, but the external output gets some strange escape codes (^[[32;1R).

----> 1 a
^[[32;1R---------------------------------------------------------------------------
^[[32;1R^[[32;1RNameError: name 'a' is not defined
^[[32;1R^[[32;1R^[[32;1RNameError                                 Traceback (most recent call last)

[takluyver]

Hi @ivan-krukov , sorry for the delay in responding.

I think we'd really like to do this without using a separate thread; threads are often a source of bugs. The idea is to use the event loop running the prompt interface to check for output from the kernel and display it. I think the simplest way to do that is to pass an inputhook function in where we call prompt_toolkit's create_eventloop. PT will then call inputhook() periodically with an argument context; so long as not context.input_is_ready(), we can poll the kernel for messages.

[takluyver]

(N.B. That's likely to be a moderate-to-complex addition of code, which is why it hasn't happened yet ;-)