[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
请先登录再写评论。
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.
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.
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.
Makes sense. I hope they can keep both and have an option in the Editor
settings pane.
Vince.
This still happens in 3311.
I wish they reverted tge behaviour to the way it used to
be in builds prios to 3296
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.
Isn't that what close all unmodified editors is for?
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.
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.
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
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.
Ok, coming build will have the option.
Also the new behaviour have been corrected