Keyboard shortcut CTRL+SHIFT+T clash in default binding between Language Server and JDT

[de-jcup]

Situation

I upgraded my eclipse IDE to:

• Version: 2022-12 (4.26.0)
• Build id: 20221201-1913
• OS : Linux

(I did not have the problem with 2022-09)

Problem: I am using CTRL+SHIFT+T more than 17 years now to show the "Open type" dialog in eclipse when writing Java code. But now there is a name clash : The language server parts have introduced same short cut for "Go to Symbol in Workspace". Because of this situation there is always a selection inside the window necessary which variant shall be used when pressing the shortcut inside a Java editor - very annoying/slowing down workflow.

Details

My current workaround

As a workaround I tried to change the default keybinding. And this was not as trivial as I would have expected.
Finally I managed to change the "Go to Symbol in Workspace" to be used only inside generic code editors and "Open type" to be used in "Editing Java Source" (But I still had to unbind the selected entry in next figure)

The final working setup looks now like this:

Wanted

The standard behavior of "Open type" command inside JDT shall work "out of the box" without any clashes with language server.

Suggested Solution

The language server "Go to Symbol in Workspace" shall have per default "when in generic code editor" and the 2Open Type" variant should be changed to "Editing Java Source" also per default.

So there would be two changes necessary: one in in JDT/Java editor command binding and another in language server binding.

[jjohnstn]

Hi @de-jcup, key-bindings across the installation of various features/plug-ins is a long-standing issue in that different projects dole out key-bindings without there being a central authority to reserve them. As you mentioned, this has been working for 17 years in Java and looking at the code, the key-binding definition in plugin.xml hasn't changed since 2005. As you might understand, there will be Java users who use the CTRL + SHIFT + T outside of the editor and this would be a loss of functionality to restrict this to only edting Java source (e.g. I can open a .properties file and still open a type via the short-cut), especially if the additional plug-ins causing the clash are not installed. I'm not sure there is a solution that works for all parties other than the current one of asking the user what to do or having the user modify the bindings via the Keys preference page to avoid the clash. Have you opened an issue against the language server?

[de-jcup]

I did not open currently an issue at the language server project. The problem is... Looking at https://bugs.eclipse.org/bugs/enter_bug.cgi I found the github page for JDT, but no hint about the Language server project. If you can give me the official issue tracker URL for the language server, I would create an issue and link this one.

And... my workaround was (as you already mentioned in your comment before) not working well : when you have not opened a java editor it did not work any longer...

So I switched the key binding for JDT back to "In Windows" (as shown in next screen). Now it works again as expected and I have at least no multi selection except when being inside a generic text editor... The most problematic part was still that the origin Language server keybinding had to be deleted (I showed this inside a picture) to avoid the clash...

My now correct working setup:

[jjohnstn]

Hi @de-jcup I believe you want to open an issue against lsp4e (assuming you have it installed) as I did find the CTRL+SHIFT+T keybinding to go to symbol in workspace.

Their github site can be found at: https://github.com/eclipse/lsp4e

[de-jcup]

@jjohnstn : I created an issue at lsp4e at eclipse/lsp4e#378

[iloveeclipse]

I think we can close this now?

Note the original issue is eclipse/lsp4e#38