Replace tmux send-keys/select-pane commands with split-window args

[kneitinger]

Hello,

First, I just want to say that I really appreciate this plugin, and thanks for all of the work on t!

I started using it with tmux recently, and really like the launching, but found it's behavior to be somewhat non-ideal.

Problem statement

When I run :SClangStart, a new pane is correctly created with the desired orientation and size, and the sc pipe command is typed, but not started. The focus remains on the newly created tab, and I must press the Enter key to kick off the command, and then manually navigate back to the original pane. Furthermore, if I run :SClangKill, Ctrl-c sclang or exit vim, the new pane remains open and is just a new shell now.

The tmux command generated in ftplugin/supercollider.vim

scvim/ftplugin/supercollider.vim

Lines 262 to 263 in d80cf6e

	let l:cmd = "tmux split-window -" . l:splitDir . " -p " . l:splitSize . " ;"
	let l:cmd .= "tmux send-keys " . s:sclangPipeApp . " Enter ; tmux select-pane -l"

ends up looking something like

tmux split-window -h -p 50 ;tmux send-keys ~/.vim/bundle/scvim/bin/start_pipe Enter; tmux select-pane -l

or:

• split window horizontally taking up 50% of the current window
• simulate typing the start_pipe command and the enter key
• return to the original pane

On 4 computers I tested this on, the send-keys approach can never kick off the command and return to the original tmux pane.

Proposed fix

In looking at the man page for tmux, I found that split-window has flags for the behavior that the send-keys and select-pane are currently handling, and they work more reliably and in a more expected way.

An example of the command generated by the refactor in this PR is:

tmux split-window -d -h -p 50 ~/.vim/bundle/scvim/bin/start_pipe

in other words:

• split window horizontally taking up 50% of the current window
• because of -d, do not focus the new pane
• run the start_pipe command and close pane when sclang stops for any reason.

This works reliably, immediately, and more ergonomically than the current approach, and feels more consistent with the behavior I was seeing when I wasn't using a terminal multiplexer.

Thanks again!