Use IDs instead of indexes to identify the Runner

preservim / vimux

easily interact with tmux from vim

MIT License

2.2k stars 159 forks source link

Use IDs instead of indexes to identify the Runner #110

Closed yunake closed 3 years ago

yunake commented 10 years ago

The IDs are guaranteed to be unique and stay constant, no matter what you do to the pane or window.

This diff is based on the idea in #81, by Roberto Agostino Vitillo (@vitillo), but rewritten to:

apply to the latest version of the source
use IDs for both windows and panes, not just panes

I have tested panes and windows as runners, both with VimuxUseNearest and without it. VimuxTogglePane() also works just fine.

This change is incredibly useful because once you have the runner, you can do whatever you want: spawn new panes, move the pane to a different window, join it back, reorder the panes and windows, change layouts, — it does not matter, your runner will remain set.

yunake commented 8 years ago

sigh @benmills

m42e commented 8 years ago

:+1:

eks commented 8 years ago

Hey guys, this is exactly what I was looking for. What about update and merge this PR? What do you think @benmills?

hodak commented 8 years ago

This is absolutely brilliant, I'm moving to fork for now. Thank you @yunake

yunake commented 8 years ago

i have no idea why @benmills didn't even show up here to comment. if he dislikes the idea, a clear communication would help clear things up and i could move on. i still use this every day and would love to see this merged. Ben, do you still plan to actively maintain vimux?

leostera commented 7 years ago

Hey @yunake, don't think @benmills is actively ignoring this :) life gets in the way sometimes.

Either way, this is something I've been meaning to look into myself -- an easy way of keeping a map between open panes and runners so that rearranging a tmux layout doesn't mess things up.

I'll be reviewing your PR promptly and we can take it from there, how does that sound? 😄

yunake commented 7 years ago

Hey @ostera I've seen you being given write access and this has renewed my interest in getting this merged. The conflicts look trivial to resolve, but I've been using my own fork for three years now and have no idea what else might've changed in the way the plugin operates. Please review and let me know what you think, this might no longer be the best approach?

yunake commented 7 years ago

I've resolved the conflicts

yunake commented 7 years ago

i'm quite busy with other stuff, i will re-test this changeset on top of current master in a couple of days and let you guys know. i think it should work :)

stellarhoof commented 6 years ago

@yunake ping

astier commented 4 years ago

6 years later hope dies last

alerque commented 3 years ago

All home is not dead. As of this last week Ben turned up and we got the repository migrated where we now have three maintainers and can add more. I'm happy to consider adding more contributors with permissions to work directly based on contribution activity.

Looking through the outstanding PRs there seems to be several that are going to conflict, but this looks like one of the more widely desired ones that people have switched to forks just to get, so I'll probably prioritize this one.