Eclipse accelerator keys do not work in terminal

[garretwilson]

I'm having trouble with basic terminal functionality in Eclipse. I originally filed eclipse-platform/eclipse.platform.ui#805, but they said to file a ticket here.

I'm using Eclipse EE 2023-06 RC1 on Windows 10. I wanted to map the keypress Ctrl+1 so that I could switch back to the editor when typing in a terminal view.

1. I went to Keys in the Preferences.
2. I made a copy of the "Activate Editor" command.
3. I set "Binding" to Ctrl+1.
4. I set "When" to "In Terminal View".
5. I opened a Git Bash terminal (by right-clicking on a project and then Show in Local Terminal > Git Bash.
6. I pressed Ctrl+1.

I expected this to take me to the editor. But instead it entered a 1 in the terminal.

If I close the Git Bash tab and click on the "Terminal" view tab itself, then Ctrl+1 takes me to the editor. However this misses the point.

The interface in general seems buggy. Sometimes when I open a terminal, it wraps at 80 characters! But then I do this:

1. Right-Click > Maximize View. (maximizes the view)
2. Right-Click > Maximize View. (unmaximizes the view)

Suddenly the terminal no longer wraps at 80 characters; it wraps at the edge of the view, as desired.

And finally I found a sequence of events to force the accelerator keys to be recognized in the terminal (but only temporarily).

1. Open a terminal view tab (e.g. by right-clicking on a project and then Show in Local Terminal > Git Bash.
2. Open another a terminal view tab. (At this point the 80-column wrapping bug suddenly presents itself.)
3. Close one of the terminal view tabs.

Now the accelerator key Ctrl+1 (see above) suddenly works! I can be typing in the terminal, and when I press Ctrl+1 it takes me to the editor instead of entering 1 in the terminal.

However when I click back on the terminal, suddenly Ctrl+1 stops working again.

[jonahgraham]

A couple of things going on here. The accelerator keys all go to the terminal by design. However I have often found it a little aggressive as it won't let users do what you are trying to do. VSCode, in comparison, does provide such configuration.

As for the line wrapping. Can you confirm which version of windows 10 you have? The bug you describe sounds like the behaviour from an older Windows 10 before the conpty API was added. If it still exists in recent Windows 10/11 then we need to fix that bug too.

[garretwilson]

The accelerator keys all go to the terminal by design.

How do we get that design changed? A terminal should not be that "aggressive". Most terminals allows some sort of "out" in order to access the external environment. This is a blocking issue. I'll simply not use the Eclipse terminal if I have to pick up the mouse to get back to the main editor. It's frankly easier to it Alt+Tab to switch over to Windows Terminal, or to switch over to VS Code (at which point I might as well stay there, because it doesn't have this issue).

Of course, I didn't use the Eclipse terminal to begin with, over two decades or more. I only got excited about the possibilities when I saw how nice it was to use an integrated terminal in VS Code, so I was hoping to do the same thing in Eclipse. I was hoping to go back to spending more time in Eclipse, as I find myself spending more and more time in VS Code instead. I guess if this is unchangeable, this will only accelerate the trend to switch to VS Code.

Perhaps no one uses the terminal in Eclipse to begin with?

As for the line wrapping. Can you confirm which version of windows 10 you have?

I just reproduced it now in Windows 10 22H2; from sysinfo:

OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.19045 N/A Build 19045

[jonahgraham]

I use it. The terminal has been around longer than VSCode has existed. As far as key bindings, if you're using vi in the terminal you may be pretty irritated if eclipse didn't pass that binding on to the terminal.

How to change things. Start with the comment here https://github.com/eclipse-cdt/cdt/blob/main/terminal/plugins/org.eclipse.tm.terminal.control/plugin.xml#L77

FWIW I use the terminal all the time, but generally on Linux.

Lets split the 80 column issue into its own bug. I suspect there is a missing resize being issued when it is git bash.

[garretwilson]

The terminal has been around longer than VSCode has existed.

Yes, but I didn't catch the relevance of that. So VS Code had to come along and show us how smooth this could be. Good for them. (I don't always praise Microsoft products, but in this case VS Code works mostly very nicely.)

… if you're using vi in the terminal you may be pretty irritated if eclipse didn't pass that binding on to the terminal.

I'm not using vi in the terminal or anywhere.

The whole point of accelerator mapping is that you define the accelerator keys to be what you want, in the context you want. The point is not "do you like the same accelerator keys that I do?" The point is, "can I define an accelerator key that is defined globally?" In fact that is what "accelerator key" is usually understood to be generally—it overrides what that keystroke would normally do in a particular context.

If we can't define accelerator keys to work in terminal, then why is there a "In Terminal View" context in key bindings?

How to change things. Start with the comment here https://github.com/eclipse-cdt/cdt/blob/main/terminal/plugins/org.eclipse.tm.terminal.control/plugin.xml#L77

It says:

      <!--
      These keybindings are needed to disable the menu-activation keys (e.g.,
      Alt-F for the File menu, etc.).  The code in method
      TerminalControl.TerminalFocusListener.focusGained() disables the Eclipse key
      binding service, but it doesn't disable the global menu-activation
      keys.
      -->

Can you give me some hints here? Are you saying that there is some way I can define an accelerator key to override the Eclipse binding service? Or are you saying it's impossible to do what I'm wanting without changing code in TerminalControl.TerminalFocusListener.focusGained()?

Lets split the 80 column issue into its own bug.

Done.

I suspect there is a missing resize being issued when it is git bash.

I have no idea, but note that I just reproduced it in another terminal other than Git Bash.

[jonahgraham]

No argument from me. The people who wrote it aren't active anymore, so it's up to us active people to decide how to resolve this. VSCode is really good in this specific aspect. The first time it traps a key that normally would go to a terminal a prompt is shown to configure the key bindings.

I don't know how to solve it,just that is the starting point. It would be great if terminal can respect key bindings. But there needs to be a way to make sure there is a way for (almost) all keys to be passed to terminal when terminal is active.

Maybe a button in the toolbar of the terminal that turns on and off the bindings is quick way to do it.

[garretwilson]

No argument from me. The people who wrote it aren't active anymore, so it's up to us active people to decide how to resolve this.

Oh, I see. Thanks for clarifying the context. 😄 Your responses make more sense to me now.

Since I'm knee-deep in trying to sort bugs from various libraries, and since I haven't been using the Eclipse terminal these many years to begin with, for me this will get lower priority. I was hoping whoever wrote this was still around and there was just some glitch or oversight. Otherwise it looks like a can of worms, and at the moment I have enough that I could go fishing every day until the year 3000.