Added possibility to choose a different session

[m42e]

Allow to specify a session which shall be used to create a new window in it.

Many developers have a second or third screen. To allow usage as output screen, this PR allows to specify a tmux session by name where the command should be run in. The current active window within the session is used if the session exists else a new session is created.

[dkrieger]

There are several places in 2285ce that rely on [window].[pane] to specify panes. This feature should change those to use the unique id of the pane instead. In general, vimux assumes we want the current session throughout the code, so some careful refactoring throughout the whole plugin would be necessary for this feature to be "complete" and integrated with the codebase, IMHO

[alerque]

Thanks for taking the time to contribute this. Much of the refactoring suggested in a previous comment has been done and the plugin is now as of #110 using IDs for panes and windows. I would be happy to consider merging this for better session interaction as well, but it will need to be rebased on master and perhaps refactored a little bit to interact well with the new way of doing things.

[m42e]

I'll update it :) Thanks for the effort you put in.

[m42e]

After rethinking it, I am not a 100% sure it is kind of required anymore. tmux meanwhile supports multiple clients viewing different windows. So you could simply use another window in the same session with an additional client attached to it.

So what do you think?

[alerque]

I agree Tmux does have another way to skin this cat. However being able to set this up in Vimux without messing with the shared client features of Tmux might make more sense in some people's workflow. I'm also curious as to whether this might fix the issue in #70. Obviously that wasn't what it was originally for, but it does seem like it would solve that problem too, no?

[m42e]

Yeah, you might be right, that may enable a workflow which is like the one described in #70. Ok, I will give it a try.

[alerque]

Does the merger of #180 render this PR obsolete?

[m42e]

No it doesn't. It is kind of the first step towards a good solution for this change. I investigate a bit further to see what's the best solution to do it.