Skip to content

feat: move tab to an existing window by orientation #4417

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

IdoKendo
Copy link

@IdoKendo IdoKendo commented Feb 7, 2024

Description

Following the PR at #3925 -- this PR adds a new feature, to move the current tab to an existing window.

This solution takes a different approach, and merges the tab to an existing window, by the relative direction, in order to provide a quicker and seamless motions, following the hjkl paradigm:

  • wh will move the tab to a window on the left
  • wl will move the tab to a window on the right
  • wk will move the tab to a window above
  • wj will move the tab to a window below

An example use case would be when a user moves a tab to a new window using the existing W binding, and now wants to merge to back to the previous window, this feature adds this option, by allowing them to merge it using wh as an example, if the previous window was to the left of the new one.

This also allows moving tabs between existing windows in order to rearrange the tabs between windows without using the mouse.

@YoavBaavour
Copy link

very interested in this feature!

@philc
Copy link
Owner

philc commented Feb 24, 2025

Thanks @IdoKendo for the PR.

  • What happens if the Chrome window is stacked behind the current one? E.g. you have two chrome windows, both maximized on the same monitor. This is a common case for me.
  • I presume this works as-is even if a Chrome window is minimized, or are minimized windows filtered out from consideration?

More generally, I think the UX for this feature needs more discussion and finalization before we implement it. See #4640.

@IdoKendo
Copy link
Author

Thanks @IdoKendo for the PR.

  • What happens if the Chrome window is stacked behind the current one? E.g. you have two chrome windows, both maximized on the same monitor. This is a common case for me.
  • I presume this works as-is even if a Chrome window is minimized, or are minimized windows filtered out from consideration?

More generally, I think the UX for this feature needs more discussion and finalization before we implement it. See #4640.

  • Stacked windows will still work, it is also a use case for myself and working with this fork for a while this is pretty seamless.
  • minimized windows are not included.

As for myself, I like the simplicity and snappiness of this implementation and have been using the fork for quite a while, but I have no issue with discussing it further.

@IdoKendo IdoKendo force-pushed the feat/move-tab-to-existing-window branch from 2bea2e4 to d0df19e Compare April 9, 2025 16:52
@landorg
Copy link

landorg commented Jul 16, 2025

I really like that approach so I installed your fork (merged with current upstream master).
For me there are a couple of problems when I use this with my i3 setup.

It seems to not always find the right window. I most of the time have multiple windows on different desktops. The direction seems to be detected by desktop number. This in my case might not be right order in my case. I have very often desktop 2,3 on my left monitor and 0,1 on the right one.
Also the handling of stacked windows isn't really working in my case. It moves tabs to other windows on other desktops most of the time.
Sometimes to desktops that are hidden.

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.

4 participants