Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can you set what pane to use dynamically? #129

Open
neumachen opened this issue Jun 2, 2015 · 4 comments
Open

Can you set what pane to use dynamically? #129

neumachen opened this issue Jun 2, 2015 · 4 comments

Comments

@neumachen
Copy link

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
Copy link

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
Copy link
Member

alerque commented Feb 14, 2021

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
Copy link

@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
Copy link
Member

alerque commented Feb 16, 2021

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:VimuxFuncs: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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants