On 29. Oct 2006, at 12:12, Nicolas Schmidt wrote:
The proper behaviour would be that only the window from which the command is run (multi-tasking ?) is affected.
Unfortunately it is not easy to block just a single window w/o bringing up a sheet (I did take an initial shot at this some time ago). It also doesn’t make a lot of difference for people who work with projects (since the other tabs will still be unavailable).
Ideally only the buffer should be “busy” and a progress indicator should appear after 5 seconds or so with an explicit “abort” button -- but that is also problematic for a few reasons (e.g. we do not want the progress indicator for commands which opens a UI, but TM can’t always spot it) and it’s a lot of work for something which until your letter hadn’t been described as “a problem with how TextMate deals with processes” nor that “It really should not be as prone to errors in external programs” -- most people know what being able to run shell commands from the buffer means, and the ⌃C / ⌘. is generally enough to keep people from totally shooting themselves in the foot with this feature.
I suppose that the subprocess spawned is synchronous (?!?).
I don’t know what “synchronous” refers to here. Since the result from the command is inserted into the document, the process is serial, yes, in that it needs to wait for the command to finish, before letting the user continue his work, just as if you ran a macro, inserted a snippet, etc.
P.S.: I tried to kill the process with ^C , but TextMate didn't seem to be able to terminate it. Instead it now became totally unresponsive, so that I had to bring down TextMate itself.
The ‘yes’ command outputs around 20 MB/s on my machine, so if you had this running for just a few seconds before you killed it, you are in for a wait.