Can you set what pane to use dynamically?

[neumachen]

Will I be able to set the pane dynamically?

Say my default config is to use the nearest pane but sometimes I want it to open a new pane instead. How would I go on about this?

[lejeunerenard]

Setting g:VimuxRunnerIndex is the key. I wanted the ability to change my vimux pane to an existing pane so I created this vimscript function and mapped it.

A way to create a new pane and set it as your vimux pane would be the following:

function! VimuxCreateNewPane()
  " Creates new Tmux pane
  let splitExitCode = system("tmux split-window")
  " Set the proper index
  let g:VimuxRunnerIndex = _VimuxTmuxIndex()
  call _VimuxTmux("last-"._VimuxRunnerType())
endfunction

When you run :call VimuxCreateNewPane(), a new pane is created and g:VimuxRunnerIndex is automatically set. The focus is finally returned to vim's pane.

[alerque]

Has this question been satisfactorily answered? Is this utility function something that should get contributed to the core and documented for ease of use and discovery or are we good here?

[lejeunerenard]

@alerque the example would at minimum need to updated as the function names have changed. In addition it should be possible to use vimux's VimuxOpenRunner() instead. So maybe an example of dynamically setting the option variables g:VimuxUseNearest, g:VimuxOpenExtraArgs, etc and then calling VimuxOpenRunner() would be better.

Alternatively adding arguments to override the default options could make it even simpler and avoid modifying global scope for a temporary and dynamic function call.

[alerque]

Thanks for jumping in @lejeunerenard.

Yes all the underscored "private" functions got renamed to be actually scoped to the plugin (_Vimux...→s:Vimux...). I'm actually considering a further refactor so that script scoped functions don't also include the plugin name (s:VimuxFunc→s:Func). Using proper scopes is the right way to handle private functions in VimL, but it does bring up what might be an API design flaw. The user function suggested here is dipping into private APIs, so it would not work in a user's RC file; it must be in the plugin itself. That's not ideal. Either the relevant API should be made public so people can do this sort of stuff in their RC without having to modify the plugin itself.

That caveat aside, I do like your ideas about how to make this easier to accomplish. Any chance you'd be interested in whipping up a PR that contributes the necessary change by adding arguments?

P.S. Dynamically settings options (aka preference values that are eval()ed) might go way. See #183.