[3296] Messed up order when closing editors

I checked the following with builds 3290 and 3296:

  • No editors are open

  • Open A.java

  • Open B.java

  • Bring A.java to front

  • Open C.java. The order of the editors is A, C, B with C active

  • Close C.java


Now in build 3290, the active editor is A.java whereas in build 3296, it is C.java.

Apparently the former policy "When closing one editor, make the one to the left active" has been replaced by something like "When closing one editor, make the most recently opened one active" (just a guess).

I think this change is very unfortunate because for the user, it is close to impossible to predict which editor will be active when closing another one. Especially when you have several rows of editor tabs (as I usually do), you lose a lot of time trying to figure out what is being displayed.

Please, Jetbrains, please restore the old behavior (or at least make it configurable).

Regards,
Jens

12 comments
Comment actions Permalink

If the new policy is "make the most recent editor tab active" please keep it. I have long wondered why this was not the policy. It makes a lot of sense to me to use a stack and push and pop references to the active file. I never liked the old policy.

0
Comment actions Permalink

The new policy is supposed to be useful but unfortunately I think it's
broken right now which makes it unpredictable. It should be fixed before
being judged harmful :)

Like Tim I'm really glad it's being implemented. The order in which I
usually work with the files is what matters, not the order in which they
were opened (especially when a project is reopened and the order is
unpredictable).

Vince.


0
Comment actions Permalink

I appreciate that others may work differently, but I really liked the old behaviour and would prefer it to be configurable. The way I work is that I like to keep track of my modified files (these show up as blue). While I am developing, I often have to open many files for inspection, but regularly like to reduce my open set of files to the modified ones. So I select the left most / top most unmodified file tab (a black one) of a block of black tabs and repeatedly hit Ctrl-F4 until that block of unmodified tabs has been closed. This workflow is impossible/very difficult now with the new behaviour.

0
Comment actions Permalink

Makes sense. I hope they can keep both and have an option in the Editor
settings pane.

Vince.


0
Comment actions Permalink

This still happens in 3311.

I wish they reverted tge behaviour to the way it used to
be in builds prios to 3296

0
Comment actions Permalink

Yes, the new behaviour is despicable. I have no clue what tab will get focus when I close something, I am no longer able to quickly close a bunch of tabs, I have to actually close, wait and figure out what has focus, then click elsewhere to close the tab I wanted to actually get focus.

I am absolutely stunned that anyone would find this intuitive or useful.

0
Comment actions Permalink

Isn't that what close all unmodified editors is for?

0
Comment actions Permalink

Making that optional should help:
http://www.jetbrains.net/jira/browse/IDEA-1672

The requested new behavior still doesn't work as intended and gives
unpredictable results, although it has improved since 3296.

Vince.


0
Comment actions Permalink

Yes, the new policy does seem to be despicable. It appears to be to close files in reverse order of their opening. It should be to close files in reverse order of their last use.
Since closing a bunch of tabs seems to be a common thread among those who want the original functionality, why not support multiple tab selection and close all selected tabs.
Of course there is always the option to middle click on each of the tabs that you want to close. Then it really doesn't matter which tab has the focus.

0
Comment actions Permalink

Of course there is always the option to middle click
on each of the tabs that you want to close. Then it
really doesn't matter which tab has the focus.


It sure does, at least if you have more than one row of tabs (which I have most of the time)! Before I middle click (or Shift-click) on a tab, I look on the tab immediately to its left because that used to be the tab of the editor that would have focus next. However, with the new behavior a totally different file gets the focus and the tab rows move around, so aiming at the next-to-be-closed tab beforehand is totally useless because in most cases, that second tab is somewhere different after closing the first.

Regards,
Jens

0
Comment actions Permalink

Actually, if you are simply trying to simulate the original functionality, position your mouse towards the left end of the desired tab and middle click starting with the first tab to close. The tab to it's immediate right will take the place of the closed tab and you can then middle click on it without moving your mouse.

I see the issue that you raise as a separate, but related, issue:
The tab rows should not move around. Currently all tab rows except the top one are adjusted to fit the width of the editor. I have no idea why. There also seems to be some kind of rational for moving tabs between the rows based on a best fit scheme. Again, why? Each tab should always be as narrow as possible while fitting the file name in it, just as is currently done in the top row of tabs. Once a tab is placed in a row, it should stay in that row unless the editor width is changed or a tab to it's upper-left has been closed.

0
Comment actions Permalink

Ok, coming build will have the option.
Also the new behaviour have been corrected

0

Please sign in to leave a comment.