When refactoring, one often moves or renames the current module (or both).
To do that, one must first find it and select it in the source tree. This can be rather tedious when you have hundreds of files, and/or nested packages (as the IDE easily promotes).
That tedium could be reduced with a small addition to an existing menu. Each source-file editor tab has such a menu: just right-click the tab.
I admit, Notepad++ has such a feature, and I use it regularly on local files.
I don’t understand the request…
The current file is automatically shown in the tree. Whether I click on a tab that is already open, or use Ctrl+P and select a file that was never open in the current session and the tab is newly opened, the tree always selects the current file (and it expands its parent tree nodes) to make it visible.
Am I thinking of something different from what you are referring to?
But if you have your Search or DB or Settings or … pane open, instead of the source tree, nothing happens in that pane. The current file is not visible. It takes some mousework to make it visible. Only then can I click on the file’s “…” to rename it, or drag it to where it needs to go.
And even if the source tree is open, the active file does not scroll into view, so once again, the active file isn’t visible, and it takes mousework (attentive scrolling) to make it so.
Not a big thing, until I get into some lengthy refactoring, and need to move/rename multiple files in a big tree. Then, since my attention has been diverted, I can lose track of where I was in the process.
The workaround for that is an additional checklist, above and beyond my usual ones.
Right, I had not noticed this.
I consider this a bug in the UI.
I do see a reason for selecting the item in the tree when the editor changes, I don’t see any reason why the IDE would select an item in the tree and not scrollIntoView it.
Perhaps this could be fixed with a shortcut similar to Ctrl+Shift+F, for example Ctrl+Shift+B, to open the left pane and the project explorer in it. This would be faster than using a menu. (I just can’t stand using the mouse when the keyboard can do the job). Obviously an explicit menu item would help people that are not familiar with all the keyboard shortcuts (99% of people).
(If the missing scrolling bug is fixed, the selection of the file would be either automatic, if the project browser is already visible, or it would require one click on the project browser icon, faster than accessing a menu.)
The best of both worlds would be a menu that shows the keyboard shortcuts.
Edit: A persistent problem with modern user interfaces is that they’ve abandoned “discoverability” as a worthwhile goal. (I’m talking to you, Apple!)
I struggle everyday to find the right words to describe my problem,
this comment
Blockquote
A persistent problem with modern user interfaces is that they’ve abandoned “discoverability” as a worthwhile goal. (I’m talking to you , Apple!)
this is perfect !!!
thanks @p.colbert
… and I would add Excel and all the Microsoft, Autodesk and other software that use ribbons. Not only are ribbons disorganized, when you resize the main window the ribbons change the size or the position of the icons, or even hide some, making it impossible to both find where a button is and learn what it looks like.
What was wrong with the old menus and toolbars, organized in a logical way, showing the shortcuts?
I want Clippy back!!
Ok, ok, stop with memory lane ranting now.
MDN now says that we should NOT create our own keyboard shortcuts for our web sites, as they run the risk of overriding those of user-provided accessibility tools (e.g., for the visually impaired).
However, discoverability (e.g., via menus) then becomes doubly important. How will those tools know what’s available, if it’s not made explicit?
We should probably split these last few posts off to the Rants category…