Ctrl-based shortcuts don't work on Linux

[jacobmischka]

In the menus, most shortcuts are listed using the ctrl key as the only modifier (likely an automatic artifact from macOS's cmd). Some examples:

• Copy ctrl+c
• Paste ctrl+v
• Close tab ctrl+w
• New tab ctrl+t

These shortcuts don't work, nor should they since they are essential shortcuts used within the shell. Copy and paste seem to work with the usual ctrl+shift+c/v, but I couldn't find working versions of any others in my few minutes of guessing.

[marcuslindfeldt]

The default shortcuts for new tabs on Linux is Ctrl+Shift+T to open a new tab and Ctrl+Shift+W to close one. Currently Ctrl+w closes the entire app.

But the reason behind it not working is because of hterm binding all keyboard shortcuts for terminal input and probably preventsDefault() so the keyboard event is not bubbling down to electron. See app/lib/hterm.js:30

[nloomans]

The problem is that the hterm thinks that when the meta key is pressed it's for hyperterm, and when not for the shell.

// passthrough all the commands that are meant to control
// hyperterm and not the terminal itself
const oldKeyDown = hterm.Keyboard.prototype.onKeyDown_;
hterm.Keyboard.prototype.onKeyDown_ = function (e) {
  if (e.metaKey) {
    return;
  }
  return oldKeyDown.call(this, e);
};

It should check if the shortcut is in use by hyperterm and if not send it to the shell.

[jacobmischka]

Agreed, and then also the menu entries need to be updated to show the correct key combinations.

[willwhitney]

Related:
In macOS you can set keyboard shortcuts (in the system preferences) that will trigger a menu item by name. If you set next/previous tab to ctrl+tab/ctrl+shift+tab via this method, they still get captured by hyperterm, and it inserts escape characters.

[nloomans]

I already fixed it, but my internet is to shitty to create a pull request... stay tuned.

[jaydson]

On my Ubuntu 14.04:

Ctrl+Shift+N > Not working
Ctrl+Shift+T > Not working
Ctrl+Shift+W > Not working
Ctrl+Shift+Z > Not working
Ctrl+Shift+X > Doesn't cut, copy instead
Ctrl+Shift+Z > OK
Ctrl+Shift+V > OK
Ctrl+Shift+A > Not working
Ctrl+Shift+K > Kind working, it clears all the terminal (looks like a bug), but Ctrl+L is working just fine
Ctrl+R > Doesn't reload, it starts the reverse search instead (which is the right thing on Linux)
Ctrl+R > Same as Ctrl+R
Ctrl+Shift+I > Not working
Ctrl+0 > OK
Zoom in and Zoom out are working with Ctrl++ and Ctrl+-
Ctrl+Shift+U > Not working
Ctrl+Alt+Left > Not working
Ctrl+Alt+Right > Not working
F11 > Not working

[arthurflachs]

Did anyone come with an idea on how to fix this ?

Apparently keyboard shortcuts are registered through the menu accelerators. Wouldn't it be better to register them through a specific service which would manage all shortcuts inside Hyperterm ?

[arthurflachs]

Most "Cmd" shortcuts (corresponding to the windows key) are also not working on Gnome 3 (with Fedora 24). They are used to manage windows position, and the events never reach Hyperterm.
"Command" shortcuts are not natural on Linux anyway.

[marcuslindfeldt]

Im with @arthurflachs that it would be great to centralize all keyboard shortcuts in some sort of service. Maybe something like https://github.com/atom/atom-keymap that could map a keyboard shortcut to an action.

[jdormit]

@nloomans what was your fix for this?

[jaydson]

I don't think it was implemented yet @jdormit , but i'm curious to see what @nloomans did :)

[jdormit]

Ah, I see. I am as will! I'm pretty new to the HyperTerm project, but if I find a work-around or a solution I'll post it here (and maybe do a pull request, if it is a good solution)

[cjb]

@rauchg Hi, any preference on which fix for this is the right one? Would you like to see https://github.com/atom/atom-keymap used?

[rauchg]

@cjb that seems like a really good solution. Like @nloomans pointed out, our approach is really naive at the moment (equating meta key to app and otherwise to terminal).

We're using mousetrap to capture shortcuts in addition to the ones set up on menubar accelerators:
https://github.com/zeit/hyperterm/blob/7a01ec77c4edcec506b79a2f8ec10cee633849cd/lib/containers/hyperterm.js#L48

[toroidal-code]

So... I don't know if this has changed or not, or if this is a solution, but @jaydson's list of shortcuts worked perfectly fine for me with the addition of the super key. e.g. super + ctrl + shift + i to open the dev console, super + ctrl + shift + u to update all of the plugins, etc. Even super + F11 to go fullscreen, oddly enough.

I'm using HyperTerm 0.7.1 on ArchLinux (installed via the AUR), but I'd assume this universal among distros.

[chopfitzroy]

@toroidal-code on Linux?

[toroidal-code]

Yeah. Well, I just tried out the text selection short and those aren't working. Which is just weird. But might be because my text-selection bindings are globally set to Emacs on my machine.

EDIT: And... it is because of Emacs bindings. ctrl + w does cut, ctrl + y does paste/yank, etc. Go figure.

[ghost]

I'm using ubuntu 14.04 and I just have to add the super key to every shortcut listed in the menus.
For example, open a new tab is ctrl + t, on ubuntu super + ctrl + t. Seems to work for most of the shortcuts (haven't tried them all)

Would be nice if I didn't have to add that super though 👍

[chopfitzroy]

@RasCarlito Using Ubuntu 16.04 can confirm that adding super to the above key combo's fixes them!

[jshbrntt]

Can you expose the keybindings in .hyperterm.js so we can quickly override them there?

[rumpelsepp]

super is not on option for me, since I am using this as a meta key in i3. :/

[fearphage]

Can you expose the keybindings in .hyperterm.js so we can quickly override them there?

I'd prefer that they work correctly out of the box.

[bogas04]

Please add #274 (comment) as a workaround in some docs/faqs until this gets fixed.

[aleksijohansson]

super not working for me on Arch Linux with Gnome 3 and I'm having all the same issues described in #274 (comment)

[matheuss]

Yo everyone please test #1058! 🙌

[n370]

So what's the actual way to workaround? I'm having no luck trying to use screen because the ctrl + a on hyper binds to select all text visible and not to screen's default control characters. I'm working on a Fedora Workstation with hyper 1.1.0. I appreciate any comment.

[cjb]

Same, ctrl-a and ctrl-r are no longer available to bash, they get used for Hyper bindings instead. This presumably wasn't the intention? I suppose one way forward would be to disable bindings like ctrl-a that conflict with common uses?

The usual thing on Linux is for the terminal to take ctrl-shift-n, not ctrl-n.

[flybayer]

@cjb, @n370 it looks like #1191 will hopefully fix this once and for all!

[divyanshu013]

Hey guys, reverse search doesn't seems to work. Any workaround for that?

[ppot]

Tag for: #1509

[rapha8l]

Hi,

Any news ?
Thanks

[ppot]

CLOSED in #1876

[rapha8l]

Thanks !
Any idea for the date of a future release ?

[MdBabji]

It was the problem with the corrupted keyboard.
unknowingly i using the same keyboard i loaded ubuntu 16, ubuntu18 even ubuntu MATE, lubuntu, etc.
but post install either the OS was hanging, and in case the OS loaded properly Ctrl based operations were not working.
so i borrowed a PC from a friend, and the same problem occurred again in the new PC, i realized and changed my decade-old keyboard with a new usb based keyboard, and all the PC's are working fine now.
no more hanging and all Ctrl based operations are working good.