[izietto]

My point of view is different: there has to be a really strong reason to move my eyes from the code, and in the editors there should be respect for that. For example, I don't want to move from Atom to VSCode because VSCode has those huge icons that take space and distract me, when all I want in the default editor UI is the project directory tree and the code. Everything else should be opt-in.

[frosted-flakes]

For what it's worth, you can easily hide those icons and access everything through the menu or command bar.

[izietto]

Right but VSCode doesn't work well with that bar disabled: for example, now I hid the activity bar (that's how it's called it seems), I clicked on a .status file and VSCode said "There are extensions for this file". I clicked on that, and now I have an extensions bar at the directories tree bar place. This happens because this UI setting is not the default one, so you encounter such kind of confusing behaviors every time you move away from the default behavior.

[frosted-flakes]

Is that a problem? There's only one sidebar. I agree there could be more, but I don't think there's much to be gained by it. Just learn the keyboard shortcut to bring up the folder tree. Or customise the icons so that they stand out less. Heck, I keep the sidebar collapsed most of the time since it's so easy to toggle it on with the keyboard.

[izietto]

I'm talking about UI/UX, not about shortcuts. If you switch my important sidebar with a marginal one it's a problem to me, from the UI/UX point of view. If you really want to talk about shortcuts: I don't want to learn the shortcut for the directories tree, because I just never hide it. And I'm talking about my flow, which might be different from yours.

[seanmcdirmid]

It actually does work well with the bar disabled. Everything is emacs accessible , the menu is just a wrapper around text commands, like they are in xemacs.

[izietto]

I've given an example of what doesn't work when you move away from the default behavior, that's the point