I already thought that my test case was as simple as possible (while at the same time being exactly described). :-)
But ok, I can instead describe it like this then:
1.
Take ANY terminal program that will read its input in a non-immediate fashion (i.e. first read some input, then do some processing/waiting, then read some more input, etc), using $(CurText) as custom input.
2.
Try to move around the cursor with your arrow keys in the editor meanwhile it’s still running and reading input.
Also, a terminal program is a terminal program (i.e. it should not be able to affect anything like this beyond the common terminal interface between the programs), so the fact that my sample is a Python program should make absolutely no difference in any way, I just chose to make the example in Python because it makes it easy to exactly describe a common terminal program to test it with (since I guess you would be hesitant to run an exe file that I send you? :-)).
Also, it sounds really strange that you should have to give up shortcuts or other keyboard interactivity just because you’re running a child process and attach to it’s output via pipes, that’s not a common Windows limitation anyway (I’m a programmer myself btw)? If all else fails, execute the pipe-polling code for the Output Bar in a separate thread, and you should then be completely safe from any such effects for sure.
I understand that perhaps most external tools that people use with the Output Bar will run for too short time for people to notice this, but for the ones who do run such external tools, this is quite a frustrating bug, so it would be really great if you could take a look at fixing it, if possible.
(oh, and I can of course send you an exe-file to demonstrate the problem too, if you would prefer this after all?)