Community
Participate
Working Groups
When ~10+ editor tabs are open, it quickly becomes difficult to keep track of them. When exploring a class hierarchy, its easy to lose track of tabs after having opened many class definitions (and the tabs get stored in the MRU). I suggest we increase the editor tab organization options available to the user. - Allow the selection of multiple editor tabs while holding shift - Allow the user to "pin" tabs, which won't be moved unless the user moves them (or unpins them). Note that the maximum amount of pinned tabs == the maximum amount of visible editor tabs (before they are stored in the MRU). Firefox already has these 2 features. I'll upload a gif demonstrating them. If anyone has alternate suggestions on how to improve editor tab organization, please feel free to share & discuss.
Created attachment 283435 [details] Tab organization (moving multiple tabs, pinning tabs) in Firefox Note: If we implement tab pinning, I don't think the tab's title should disappear when pinned. Instead, a pin icon or some other visual indication should appear to indicate that it is pinned.
(In reply to Andrew Obuchowicz from comment #1) > Created attachment 283435 [details] > Tab organization (moving multiple tabs, pinning tabs) in Firefox > > Note: If we implement tab pinning, I don't think the tab's title should > disappear when pinned. Instead, a pin icon or some other visual indication > should appear to indicate that it is pinned. Also, in Firefox a user cannot move a pinned tab - it moves to the far left automatically and stays there while pinned. This behavior is most predictable, so I'm +1 with doing a similar approach. Although being able to move a pinned tab could be nice.
Note that Eclipse has already editor pinning, however that does not keep the tab visible, it prevents an editor from being auto-closed. It to the use this difference should be clear, or the new suggested behavior should replace the existing behavior.
(In reply to Rolf Theunissen from comment #3) > Note that Eclipse has already editor pinning, however that does not keep the > tab visible, it prevents an editor from being auto-closed. Thanks for letting me know Rolf, I hadn't noticed this till you pointed it out. > It to the use this difference should be clear, or the new suggested behavior > should replace the existing behavior. Personally I don't know if the existing behavior should be replaced or not. I've never used the existing "pin editor" feature but maybe other users use it frequently? I'll look into the current implementation of editor pinning to see if any logic could be reused for my proposal. I do think strongly that editor pinning should be accesible when right clicking an editor tab (no need to search for an icon to activate it) and that the selection of multiple editor tabs should be possible when holding shift.
