Seems they've broken it slightly in 2022.2 EAP

[momomo]

Moving / shifting a tab to splitter unfortunately now seems to leave focus behind.

[PascalSenn]

@dkandalov The problem that @momomo describes behaves as the following:

1. Open Document A
2. Open Doucment B
3. Shit Document B to the Right
4. Cursor is in Document A in the Left pane

Previously:

1. Open Document A
2. Open Doucment B
3. Shit Document B to the Right
4. Cursor is in Document B in the Right pane

[dkandalov]

Thank you for reporting the issue! It should be fixed in version 0.32

[PascalSenn]

@dkandalov Thank you for your efforts ! At least for me it does, unfortunately, not fix the issue. I move a tab to the right, but the focus stays on the left

[huyz]

I just tested 0.32. The focus does move if a new split pane is created. But the focus stays if the split pane already existed.

[dkandalov]

@huyz I uploaded 0.33 which should fix that (tested in the IJ EAP version built from latest source code).

[PascalSenn]

@dkandalov can confirm, works for me! Thanks a lot!

[momomo]

Awesome, can confirm. Works here too! Now I can disable my karabiner dirty fix.

While I have you @dkandalov on the line, would you ever, ever, possibly ever, be able to conceive of a way of moving an entire splitter left, right, top, down?

Sometimes, you might have the CSS, or HTML, JS, JAVA group in separate/dedicated splitters, but looking to work on the main monitor with that just one. Focus on JS right now. Focus on Java. We all have our favorite location for that.

Personally I am not really sure how that can be devised, UI wise. But I have been giving it quite some thought over the years.

If a splitter group where to "switch" place with another splitter group, do they just swap? Would that perhaps cause too much mischief? Lead to chaos? Not a great way.

Another possibility is that one moves a splitter group left, and allows for a drop down meny on the new one containing TWO or more groups.

The original splitter group could then be left blank and empty, for another group to move into.

There are ways to do this but let me know if any of this is making any sense, and if not, I can provide more context.

I think since you are already manipulating tabs and splitters, you are best suited to introduce this kind of feature. I do think it would be a killer feature never before created on any application.

We now have a tab moving left/right/down/up but to reorganize a group of them, say all java to the right and move back all the js ones, to the main screen is an annoying undertaking currently, even with this plugin although it certainly beats the alternative.

What if we can move an entire group, shove it to the right bottom corner along with a couple of others, and thus allow for tab groups to be parked in a list. Then they can be iterated over keyboard shortcut + up down and then moved into the right splitter of our choice.

Surely, this would take more time of you, but structurally it could be easy. Just treat splitter groups in an arraylist, and allow us to pick one with a shortcut in the current active editor. Up/down. When moving left/right/up/down you just add it to the list in the next splitter. The active one is deduced by an index. Later one can do more crazy things such as reorganize the list order and so forth.

Hope I am making any sense?

Perhaps you do not have the time?

[huyz]

@momomo what you're talking about is commonly done in vim. That's because in vim, split panes (which they call "windows", confusingly) are children to tabs, not the other way around. So this means that all that can be done is move entire split panes (or what you're calling "splitter groups").

There are two solutions I have seen:

• built-in: there are operations like "move all the way to the left" and "rotate" and "exchange with next" (whatever that means): https://vimdoc.sourceforge.net/htmldoc/windows.html#window-moving
• plugin: you can select two panes to swap: https://github.com/wesQ3/vim-windowswap

[momomo]

@huyz I see! Interesting with vim! I wish I could invest the energy to learn it properly!

The first/built-in way sounds like the one I mentioned which I suspected could lead to a "chaos".

The second/plugin way I've also considered but that might be a bit cumbersome, since when you swap, you might not actually desire one of the swapped splitters to be where they are now. You actually just desire to have one tab group in a specific place.

Therefore I would consider the proposal I had as a third option. Creating a splitter group / list within each splitter area. That allows you to save away and rotate splitters in place.

One can go even further, and then save an entire workspace away in the same way if one treats the entire workspace as a big splitter group. Then you can have one to many workspaces. ( I have built a plugin for that myself ).

Of course my proposal might be a bit more complex to implement than swapping of course. Requires also persistence between restarts.

[dkandalov]

@momomo thanks a lot for sharing the ideas!

I've been mostly working with a single open editor on laptop for the last couple of years, and haven't given much thought to organising several files on the screen. The initial use case for this plugin was just to see prod and test code next to each other (left and right). Admittedly, I went way too far generalising it.

I wonder what are the fundamental reasons for you to have two files open at the same time?

Sometimes, you might have the CSS, or HTML, JS, JAVA group in separate/dedicated splitters, but looking to work on the main monitor with that just one.

This is interesting because I never used a splitter with a particular file type. Could it be a feature to open certain file types in their own splitter?

If a splitter group where to "switch" place with another splitter group, do they just swap? Would that perhaps cause too much mischief? Lead to chaos? Not a great way.

It's not very clear to me what you mean. In my experience one of the best ways to know what actually works is to try all the approaches. Tab-shifter was originally a showcase for https://github.com/dkandalov/live-plugin but IntelliJ editor/splitter API turned out to be more messy than expected 😅

If your setup doesn't include deeply nested splitters, you could possibly achieve what you want with custom actions, e.g. to swap splitter editors in Kotlin (this is a hacky code which is hard to write without looking at IJ source code though):

registerAction("Swap Split Panels") { event ->
    val manager = FileEditorManagerEx.getInstance(event.project!!) as FileEditorManagerEx
    val splitter = (manager.splitters.getComponent(0) as javax.swing.JPanel).getComponent(0) as Splitter
    splitter.swapComponents()
}

I think it might also be possible to swap panels between any splitters because this is the implementation of com.intellij.openapi.ui.Splitter#swapComponents:

  public void swapComponents() {
    JComponent tmp = myFirstComponent;
    myFirstComponent = mySecondComponent;
    mySecondComponent = tmp;
    revalidate();
    repaint();
  }

[momomo]

@momomo thanks a lot for sharing the ideas!

I've been mostly working with a single open editor on laptop for the last couple of years, and haven't given much thought to organising several files on the screen. The initial use case for this plugin was just to see prod and test code next to each other (left and right). Admittedly, I went way too far generalising it.

I wonder what are the fundamental reasons for you to have two files open at the same time?

I think, although this is old school, being a fullstack developer you'd often work with related code, so html, js, css, backend/java is all connected thus you might want them all easily accessible as you move back and forth, glean on one and go back to the other.

On a multimonitor setup it is very handy to have certain code easily accessible in an an already open splitter. It also almost works as bookmarks as you can go to project file location using an already open editor as well. That way you can pull up more css.

Sometimes, you might have the CSS, or HTML, JS, JAVA group in separate/dedicated splitters, but looking to work on the main monitor with that just one.

This is interesting because I never used a splitter with a particular file type. Could it be a feature to open certain file types in their own splitter?

Not by auto, not really. I'd opt for control of being able to move them and group them myself, although I'd say most of the time I do end up with such groups, but sometimes, one task, module, or directory might end up with files in one splitter, unrelated by type.

We often work on tasks, right? So a task might involved a set of files, and those files might be interesting to have all open at once. To do that you must use splitters. Right?

However, if you now need to move on to another task momentarily, you often need to close down all the open tabs and editors. How can we just start a new task, and save away the other one, either in a splitter, or ....

If a splitter group where to "switch" place with another splitter group, do they just swap? Would that perhaps cause too much mischief? Lead to chaos? Not a great way.

It's not very clear to me what you mean. In my experience one of the best ways to know what actually works is to try all the approaches. Tab-shifter was originally a showcase for https://github.com/dkandalov/live-plugin but IntelliJ editor/splitter API turned out to be more messy than expected 😅

If your setup doesn't include deeply nested splitters, you could possibly achieve what you want with custom actions, e.g. to swap splitter editors in Kotlin (this is a hacky code which is hard to write without looking at IJ source code though):

Not really interested in hacking something temporarily. Just saying this would be a powerful feature. To go beyond and offer something spectacular with something I mentioned as workspaces, but it depends on how committed you'd be to spend that time.

I think you have the foundation to just keep going, but as you only work on one monitor it probably be difficult to convince you to spend that time since you personally does not have the need.

We could have a chat someday, and perhaps I can show you my screen and then perhaps it would be easier to comprehend. For me the use case comes from maintaining a large and mixed codebase that is intertwined.

registerAction("Swap Split Panels") { event ->
    val manager = FileEditorManagerEx.getInstance(event.project!!) as FileEditorManagerEx
    val splitter = (manager.splitters.getComponent(0) as javax.swing.JPanel).getComponent(0) as Splitter
    splitter.swapComponents()
}

I think it might also be possible to swap panels between any splitters because this is the implementation of com.intellij.openapi.ui.Splitter#swapComponents:

  public void swapComponents() {
    JComponent tmp = myFirstComponent;
    myFirstComponent = mySecondComponent;
    mySecondComponent = tmp;
    revalidate();
    repaint();
  }

[momomo]

Latest Intellij version seems to have unfixed this issue. It has now reappeared !

2023.3

[momomo]

I will try to install the previous version, 0.32.

Tried it but getting the same behaviour.

Issue now, is that sometimes this will work, so I am not sure my karabiner fix will work this time around.

I will almost have to disable this if it has inconsistent behaviour.

Jetbrains keeps breaking plugins!