Closed lackac closed 10 years ago
After a little thinking and poking around with the Atom API and in the source of other packages I realize that most of this could be implemented in a separate package. The only thing that's missing is a way to access active sessions. I personally would prefer a separate package as it could focus only on the runner aspects.
What do you think? If you agree, I will open a separate pull request just for tracking active sessions, and create a separate package that builds on that.
With regards to tracking sessions, what makes it difficult is that simply closing the tab on an active session doesn't send any event that could be listened to in order to remove the session from the list. Currently I'm cleaning up session destroyed like that by catching the "Cannot send message to terminated process" error.
I think keeping changes to terminal minimal would be great because we're not prioritizing it right now. The smaller the diff, the easier it will be to merge. If the functionality proves to be useful and popular then we can roll it in when our focus turns to terminal in the coming months. Thanks for your time and interest!
In the end I was able to create this as a separate package without any necessary changes to the terminal package: terminal-runner Thanks for the feedback!
It is many times useful to be able to run a command remotely. Think unit tests or build tasks. This is a first shot at providing that feature.
The new
terminal:run-command
(mapped toctrl-r
) command opens a command prompt at the top of the window and sends the provided command as input to the terminal session that was activated first. It tracks active sessions, and removes sessions when they are exited or their tab closed.There's also a
terminal:run-last-command
(mapped toctrl-shift-r
) command which runs the last command again.I also included a little bit of refactoring in
terminal.coffee
making thecreateTerminalSession
function a method onTerminal
. It made sense for easier tracking of active sessions. I know it's best to keep refactoring as separate commits, but I was already too deep into it to go back. However, if you don't agree with the way I did it, let's discuss and in any case I can add it back the way it was.I'm also thinking about how to allow the user to select which session the command runs in. One way would be to add a shortcut under the
.terminal
scope for selecting the currently active terminal tab as a target for commands. Another would be to open a new terminal tab on the first command and keep using that for subsequent commands.As I said, this is a first shot. I would love to get some input, thoughts for improvements, etc. I will add specs for the new features later.