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

Extend Vimux to add option 'VimuxUseLast' #143

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

dkrieger
Copy link

@dkrieger dkrieger commented Jul 12, 2016

Description:

Add option to use last-active tmux pane as runner pane.

  • When g:VimuxUseLast == 1, use last pane as runner pane. This pane can be in any window.
    • Notable effect: Vimux will only create a new pane when there is no last pane (i.e. last pane is the current pane)
    • Behavior could be changed to only use last pane if it resides in same window as vim, if this is preferred (Update: said change is in the most recent commit)
  • This option overrides g:VimUseNearest
  • 206ecb fixes a (pre-existing) bug whereby Vimux would no longer create a new runner after closing the runner if a pane with same [window].[pane] signature exists in a different tmux session. If maintainer prefers only the bugfix or only the feature, they exist in different branches in my fork and this pull request can be easily amended.

Motivation:

Vimux offered no user-friendly way to make an arbitrary pane the runner. With this patch, a user can just select the pane they wish to be the runner, then selectp -t [vim's pane]. If the desired runner pane is a tmux keystroke away, there's no need to enter tmux command mode at all.

Disclaimer:

This is my first pull request, sorry if this violates your guidelines, is incomplete, and/or is poorly formatted

Copy link
Member

@alerque alerque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking the time to contribute this. It will need a few touchups before we can merge though. The fork notice shouldn't be part of this PR at all, some of the other code will need rebasing, and we need some help docs. Are you interested still? If so I can help with the details...

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

Successfully merging this pull request may close these issues.

None yet

2 participants