[LifeTimer]

If I’m currently running an External Tool in the Output Bar, and then (while the first tool is still running) try to start another External Tool, a dialog pops up asking me if I want to terminate the currently running job.

Even if I answer “no” to this question, the Output Bar is still cleared and the new tool is started, which seems wrong to me? Unless the question only refers to if I want to terminate the old job but still execute the new job and let it take over the Output Bar? In the latter case, it might be good to make the question a bit more clear in regards to that.

Please also see the related suggestion I just posted about the Output Bar and multiple running External Tools here:

https://www.emeditor.com/forums/topic/multiple-tabs-in-output-bar-for-concurrently-running-external-tools/

[Yutaka Emura]

Hello LifeTimer,

This is actually the correct behavior. When you click “No”, the previous job will still continue to run, but it won’t show in the Output Bar because the Output Bar is used only by one job. You just can’t see the progress or the result of the job anymore.

I hope this clarifies your question. As for the multiple tabs, this might take a long time to implement.

Thanks!

[LifeTimer]

Ok, thanks for the clarification!

Too bad about the tabs in the Output Bar though, I’d really need some efficient way to run several external tools at the same time and still get all their results. :-(

I just tried to instead solve this by choosing “Create New Document” as the output method of the External Tool. I immediately stumbled into three different problems with this though:

1.
I found a bug related to the “Create New Document” output method I think: If I start the first instance of the tool with one selection of text in the document (i.e., the tool in question gets its input from $(CurText)), and then start a second instance of the tool before the first one has completed its execution, I get the dialog discussed above about terminating the first instance. If I select “No” there, the second instance starts, and when it finishes, two new documents are opened in EmEditor with results, but both of them contain the results of the second instance, while the results from the first instance is gone. (the same happens if I run three parallel tools of this type, i.e. three tabs are then opened, but all of them just contain the results of the last started job out of the three)

2.
The dialog that pops up each time asking me if I want to terminate the currently running job disrupts my workflow.

3.
The fact that the new documents pop up in the foreground (that is, that they are created AND switched over to from the original document that I’m working in) completely disrupts the workflow too.

In order to solve this, I would humbly ask you if it would be possible to:

A) Fix the bug that I mention above in point 1.

B) Make it possible to “remember the answer” of the “do you want to terminate the current tool job” dialog, so that it never pops up again.

C) Make it optional to output the results in a new document that will not be switched over to in the editor, i.e. a “background document” (just like you can open links into new tabs in web browsers, without actually switching over to that tab automatically at the same time).

Would this be possible?

[Yutaka Emura]

Hello LifeTimer,

I fixed this issue on beta 5. Basically, the “No” option is not available anymore.

Thanks!

[LifeTimer]

Hmm, ok, but if you simply just removed the “no” option, doesn’t this mean that the currently running job is always terminated, thereby eliminating completely the possibility of running parallel External Tools that can present their results in separate new documents, right?

If that is the case, it is the exact opposite of what I needed. :-(

Wouldn’t it rather be quite easy to just enable the jobs to store their results in separate memory buffers, thereby enabling the possibility to run separate jobs and present their results in new individual documents as they finish, for anyone user having such needs?

[Yutaka Emura]

Hello LifeTimer,

I will think about improving the external tools so that each tool can use an independent buffer, but it will take some time. It also depends on priorities. If more customers would like this feature, then I would have to add this sooner. Please let me know if any other users would like to have this feature.

Thanks,

[LifeTimer]

Ok, thanks!

I’m a software developer myself, so I know about the necessity of prioritizing feature requests (especially time-consuming ones)… :-(

Still, adding a thread-local buffer if threads are already used (or if asynchronous I/O is used, mallocing and keeping track of separate buffers) shouldn’t hopefully be super time consuming after all, so hopefully it won’t at least have to be sent to the very back of the queue for “time consuming and complicated features to implement sometime in the future” queue. ;-)

Oh, and again please do note that the multi-tab thing for the Output Bar is completely superfluous if only the results can be dumped to separate (background) tabs in the editor instead, for which the code (except the background part) already seems to be implemented too?

[Author]

Posts