christoomey / vim-tmux-runner

Vim and tmux, sittin' in a tree...
MIT License
291 stars 37 forks source link

Option to tell VTR to attach to the first terminal it finds #60

Closed naps62 closed 7 months ago

naps62 commented 8 years ago

I'm sorry if this was asked before, I couldn't find it...

During my day, I restart vim a lot, so I end up having to re-create the runner pane all the time. Most of the times, I will close vim, and end up opening it again later, all this while the original runner panel is still there. It would be useful for me tell VTR that, when he isn't attached to any pane, and I ask him to run a command, he could just run it on the next pane it finds in the current tab

Is this currently possible?

christoomey commented 8 years ago

Hey @naps62, thanks for the question. This idea in various forms has been tossed around, but I don't think exactly what you're asking has been discussed. Currently it is not supported.

I personally want VTR to be as conservative as possible as I often use killRunner and am interacting with production systems via it, so I'd rather have to be extra explicit than have any mixup there.

That said, I think we could add a new command that supports your desired workflow. Roughly what I imagine is a new command, perhaps :VtrRunWithAssumedPane or similar, and it would:

@naps62 what do you think of the above? /cc @gabebw @gfontenot for any thoughts you might have.

gabebw commented 8 years ago

I would LOVE to have this feature.

Sent from my iPhone

On Mar 12, 2016, at 3:47 PM, Chris Toomey notifications@github.com wrote:

Hey @naps62, thanks for the question. This idea in various forms has been tossed around, but I don't think exactly what you're asking has been discussed. Currently it is not supported.

I personally want VTR to be as conservative as possible as I often use killRunner and am interacting with production systems via it, so I'd rather have to be extra explicit than have any mixup there.

That said, I think we could add a new command that supports your desired workflow. Roughly what I imagine is a new command, perhaps :VtrRunWithAssumedPane or similar, and it would:

Use an "attached" pane if set (with sanity check logic to make sure it exists, isn't the Vim pane, etc) Try to attach to the "next" pane (would this by the numerically higher pane?) Open a new pane if only the Vim pane exists (maybe?) @naps62 what do you think of the above? /cc @gabebw @gfontenot for any thoughts you might have.

— Reply to this email directly or view it on GitHub.

naps62 commented 8 years ago

Hi @christoomey

I entirely agree with being conservative. I don't use this in production myself (at least not yet), but I understand the dangers in that

About the VtrRunWithAssumedPane suggestion. I'm not sure I understand how that would work. Would I use that instead of VtrSendCommandToRunner? If so, how does that play with the various commands that exist (SendLines, SendCtrlD, etc.)? Or would it be a configuration function that tells VTR to look for an assumed pane in the next VTR calls? I would expect the second one to be the case, although it might make more sense as a config option rather than a command

To clarify, what I wanted to be able to do was: press <leader>s (call vim-rspec, which I set up to use VTR) without having opened a runner first. If another terminal was available, attach to that, otherwise, open one with the orientation and size that I usually specify.

I believe this matches the your described flow, more or less. About attaching to the "next" pane: I believe that would work for me as I usually use vim on the left-most terminal. Other people might have it the other around though