Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Move Pane to Tab (GH7075) #10780
Move Pane to Tab (GH7075) #10780
Changes from 13 commits
0fb4b38
4adfdee
e33b7aa
64346fb
d66d02e
b8e95e3
3bb24b2
4077160
a7d7aec
e7a9d21
eea166c
abe6a2b
530f658
d1ed59c
23b1ccf
ae1a84a
ef5089f
2188f6b
c6c9cc1
012747a
4d9e571
e91c69c
61a3cae
1e048e2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright so this is a wack idea that might need socializing with the rest of the team, but I wonder if it would make sense to just combine this functionality with the
move-pane
action? Thoughts on the matter:mptt
is kinda a black swan here - all the other short forms are two characters.mp -t 0
, the long form could actually just be--tab
🤔mp -t 0 left
now is a little weird, "move the pane to tab 0 (to the left???)" That doesn't make sense. The two options (direction
and--tab
) would have to be exclusiveMovePane
andMovePaneToTab
) that are exposed through a single commandline interface.move-pane --tab 0 --parent 4
which would move the pane to be a sibling of pane 4 in tab 0.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ultimately, I don't have a strong preference either way since I currently don't plan on using the command line version at all. If there is a desired change to the command line parsing I can try to figure out how to implement it.
One of the other things I was thinking about while implementing this is, especially forward looking, that you could have a target pane, and a
SplitStyle
. E.g. if directional split and drag and drop is added, the underlying command might be like "move pane to tab 2, with target pane 5, split and place on the left side." That is at least a couple of features away, so I don't know how much it makes sense it build that in quite yet. As for the command line interface for such a feature, I'm not sure if it needs to be so involved, but I also just don't know the use case.I think one of the possible issues is that the naming here is not quite consistent with intent (and I am at fault for that).
move-pane
actually isswap-panes
in that it switches positions of two things, whereasmove-pane-to-tab
takes the current pane and puts it somewhere else, and otherwise doesn't disrupt the positioning of other panes.For a last thought, I am comfortable with vim and its notion of commands and movements being separate. Here, commands would be like
move-focus
,move-pane
,move-pane-to-tab
, etc, and the movements/targets would be likeleft
orprevious
orpane with id 1 on tab 3
. If everything were to be rearchitected in this style, we could have more of the "command" style things just takePane
s as arguments, and then hypothetically a command likemove-focus
could gain new abilities if we added afirst pane
orneighbor of parent
"movement" (or just be removed outright in favor offocus-pane
). Such a change is of course highly subject to opinion and would require more discussion.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've definitely got some good points here. I think the
bit is definitely a specifically good argument. Almost seems like we should rename the existing
move-pane
toswap-pane
, but then that wouldn't be able to have a two-letter short form, so that's annoying.However, in the team discussion we had, I think the general consensus was to have this be exposed as
move-pane --tab <id>
. The commandline is kinda it's own UX, and the consensus was thatmove-pane-to-tab
didn't really feel ergonomic. That, and we were thinking about maybe in the future of something likemove-pane --window 2
or something likemove-pane -w new
. (admittedly, that's all waiting on #1256 and #5000). Those commands seemed pretty clear in what they were trying to do, and simpler than the equivalentmove-pane-to-window -t 2
.Lemme double check with the
tmux
man pages. They have pretty good precedent for all this usually.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be fine to just merge the command line portion and have that call the separate actions, or should there be a higher level of integration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so taking a look at the man pages:
tmux man page selection
So they definitely don't allow
move-pane -t 4 left
, because that's nonsensical. "move the pane to tab 4, then move it left"?Maybe we should follow their lead on this one.
swap-pane [up|down|left|right|prev|nextInOrder|prevInOrder]|[-t,--target tgt-pane]
move-pane
, so this would be a rename, but without a short form (sad, but okay)nextInOrder
(etc) values after Allow moving through panes in ID order #10909-t
argument in another PR, as an exclusive arg with the directionmove-pane [-t,--tab index]
: move the pane to the given tab. Ifindex
isnew
, then moves it to a new tab.[-w,--window id]
for moving to another window.[-d,--destination pane-id]
: split the given destination pane rather than the active pane in the taband I suppose with both we could ass a
[-s,--source pane-id]
arg as well.I might just be openly brainstorming at this point. What do you think? we haven't shipped
move-pane
yet, so we're definitely still free to change it if we feel there's a better nameThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea we definitely thought it was okay to do that. Having two actions internally for one subcommand is kinda weird, but is definitely easier to deal with logically than trying to combine them into one args blob with optional properties and all that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to rename
move-pane
toswap-pane
andmove-pane-to-tab
tomove-pane,
or to just make it allmove-pane
just let me know. Bit annoying to dig through all the resource files again but its not too bad.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, the team did feel that we should just do it all on
move-pane
, I've just been brainstorming myself over here since re-reading this thread this morning.I'm trying to think of all the moving things we want to do with panes, and coming up with a single command that looks like... this?
and I think all that together means that we want to
and if these were all on one command, then I don't think it works. We'd need
tab
anddirection
to be exclusive to differentiate between 1 and 2. But thendirection
anddest
would need to be exclusive for swap, but not exclusive for move, and now the rules don't work.So in conclusion, yea:
(sorry for the runaround on all this!)