[tree] RETURN should not expand nodes

[JanKoehnlein]

RETURN should not expand a node, at least if they are openable.
This yields to strange behavior in the call hierarchy: When you hit RETURN on a node, the respective call gets highlighted in the editor, the editor grabs the focus and the node is expanded. The latter feels odd. To expand a node using the keyboard you can still use left-arrow.

[epatpol]

@JanKoehnlein This seems to work now no? Should we close it?

[JanKoehnlein]

@epatpol it has been locally fixed for call hierarchy, but not for trees in general, e.g. the navigator.

[vince-fugnitto]

I believe this issue should be closed.
We have the same behavior as VSCode, tree nodes can be collapsed/expanded using ENTER

[JanKoehnlein]

Checking with VSCode again, in the explorer RETURN on a node triggers rename and doesn't expand.

[vince-fugnitto]

I tested against the latest vscode (I also don't have any custom keybindings):

[JanKoehnlein]

Also latest VSCode, but on a MacBook, German keyboard. There is no additional ENTER key as on Windows, just RETURN: RETURN triggers rename.

[vince-fugnitto]

@JanKoehnlein I initially tested on Linux. I re-tested using Mac and I see that ENTER triggers a rename in the navigator. The fix then is thus likely to be OS-dependent.

[vrubezhny]

@JanKoehnlein Does it mean that we have wrong behaviour in Class Hierarchy and Type Hierarchy Dialogs then?

[vince-fugnitto]

@JanKoehnlein I believe that in general ENTER should expand/collapse nodes, and only if some other functionality is required (ex: 'explorer' with the rename) should the individual tree override the default behavior. In the case of 'class hierarchy' and 'type hierarchy' the ENTER was problematic and thus was updated to not expand/collapse nodes. In most cases ENTER to expand/collapse aligns with VSCode, but we can take a look at individual cases to see which trees should not be expanded/collapsed with it.

[JanKoehnlein]

Our problem is that we want to mimic VSCode behavior as close as possible while VSCode behaves differently on different OSs. Keybindings seem to be particularly problematic, as it is even hard to detect the keyboard when running in the browser.

I'd vote for keeping it simple and just put the same default behavior for all OSs and runtime scenarios (electron and browser), e.g. as you describe it. I cannot foresee whether that will bring us trouble in the long run, e.g. when running 3rd party VS Code extensions.