[LifeTimer]

I have several different “External tools” configured in EmEditor, in turn connected to keyboard shortcuts, which is a very handy feature.

One quite aggravating detail I have noticed in connection to this though is that the arrow keys on the keyboard stop working (won’t move the cursor etc) in the editor while such an “external tool” is executing.

Please note that this has nothing to do with GUI focus issues (I can still select anything in the editor with the mouse, but the cursor still won’t move if trying to press an arrow key right after this), and also that it only happens while the external command is still running (for example, I have an external program that will do some processing for 10 seconds before returning its results and exiting, and in this case it is during these 10 seconds of initial execution that the arrow keys won’t work in EmEditor, but as soon as this external tool has returned its output and exited, it works again). It is also not a CPU load related issue, because I have a very powerful computer, and all other operations still go lightning fast when this happens, it is only the arrow keys that stop working.

Any way to fix this?

[Yutaka Emura]

Hi LifeTimer,

What is the external tool that causes the problem? Is it a console application? Can you let me know an example that causes the issue?

Does changing the external tool options (for example, “Use Output Bar”) help?

Thank you,

[LifeTimer]

Sorry for not providing enough details. After trying to put together a PoC, it appears that the problem is a bit more specific than I first thought.

My external tool is indeed a terminal program, and it’s using the Output Bar.

Here is a PoC that you can use to reproduce this bug-like behavior:

Run the following Python script as an External Tool:

import sys
import time

print "Starting processing, arrow keys (cursor handling) won't work correctly in the editor from this point."
sys.stdout.flush()
for line in iter(lambda: sys.stdin.readline(), ""):
	print ("You entered: " + line).strip()
	sys.stdout.flush()
	time.sleep(2)
print "Processing complete, now the arrow keys (cursor handling) will work again."

Using the following external tool settings for it:

Command: C:\Python27\python.exe (or whatever your Python path is)
Arguments: C:\your\script\path\emeditor_bug_poc.py
Use Output Bar: Yes (checked)
Input: Custom: $(CurText)
All other fields empty/default.

Now simply select multiple rows of text in the editor, and then run this external tool (either by using a shortcut or by executing it from the menu, it doesn’t matter).

For my test, I selected the following rows:

111
222
333
444
555
666
777

Now, while it is running, try to move the cursor with the arrow keys (first click in the editor to get the GUI focus there), or insert text into the document. You will see that the cursor turns “grey”, and in my case it jumps all over the place when I press some arrow keys, even to positions outside of lines, where it could not normally be placed. Also, all characters you enter in the document end up in the output bar instead of the document, even though GUI focus is still in the document.

It also seems that this only happens when I define the custom input as “$(CurText)”, or at least not when I define it as the same static contents that I’m selecting when using “$(CurText)” (i.e. 111, 222, 333, as described above), so this might be an important clue to reproduce and solve this too.

In my original (non-PoC) use-case where I discovered this behavior, the cursor just freezes completely instead and becomes impossible to move at all, but I guess it depends on the input behavior of the external tool program that is running. It seems like somehow the input of the running program is mixed together with the actions performed in the document anyway, which does indeed seem like some kind of bug, or at least a problem for the user.

[LifeTimer]

Are you able to reproduce this too (or at least similar abnormal cursor/input behavior in the editor for such external tools taking their input over a non-instant period of time)?

[Yutaka Emura]

Hello LifeTimer,

No, I have not tested yet. I don’t have Python installed on my computer, so it will take some time to test it.

Can you reproduce the problem with another external tool? It might be an issue only specific to Python. I am not sure what your Python script does, but if your Python script expects any keyboard inputs, then I think EmEditor will have to give up keyboard shortcuts. Thus, this is an expected behavior.

By the way, I would appreciate if you could make a test case as simple as possible.

Thanks!

[LifeTimer]

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?)

[Yutaka Emura]

Hello LifeTimer,

Can you please let me know all the settings you used for the External Tool Properties? If the Output is “Replace Document”, “Replace Selection”, “Insert Before Selection”, or “Insert After Selection”, the cursor position can be adjusted after the output is redirected to the editor.

I would appreciate if you could send me an EXE file that you used as a “terminal”, and a sample file you opened with EmEditor, and the screenshot of the External Tool Properties, so I can reproduce the issue. You can email them after zipped to tech @ emurasoft.com.

Thank you,

[LifeTimer]

Ok, I have now created a PoC exe file instead, and emailed it (together with the other requested information) according to your request above.

Also, one more important thing I noticed about the bug is the following:

When you execute the PoC external tool using a shortcut, the Output Bar will appear and the GUI focus in EmEditor will go to that (I don’t mean that this is part of the problem, it’s just the normal behavior leading up to my next step in the description here below).
If you then click the editor part of the GUI once after this, the cursor will appear and you will seemingly be back in the editor, and this is when the cursor will behave strangely while the PoC program is running (try to move the cursor with the arrow keys at that point, for example to the left, and you will see).
BUT, if you click the editor window once again, the cursor problem will disappear!

That is, important to note:
This bug only happens if you click the editor part of the GUI once to get back to it from the Output Bar while the external tool is running, BUT if you click it again, the bug will disappear and you won’t be able to reproduce it!

[LifeTimer]

I have now sent you a new PoC that reproduces the problem 100%.

The bug is seemingly related to the “Show as Tool Tip” output option for external tools. If this option is selected for an external tool, it will be impossible to move the cursor (with the arrow keys, but not with the mouse) inside the editor window for as long as the external tool is executing.

I hope this will make it possible to fix this bug.

(so, it seems that this cursor freeze and the other previously discussed (by now fixed) cursor problem were two separate bugs!)

[Yutaka Emura]

Hello LifeTimer,

I reproduce this issue, and it will be fixed on the next beta version.

Thanks!

[LifeTimer]

Excellent, thanks!

[Author]

Posts