Hyper: Alt issues

[rauchg]

To continue the now closed PR https://github.com/zeit/hyperterm/pull/201
We might have introduced a regression with alt handling.

On german layout, ~ doesnt show up for alt/opt + n. i can hack it there while typing alt + shift + n and deleting the unicodes before the ~.

cc @patrickhaug @marcbachmann @teemuteemu

[nfcampos]

another alt behaviour still not resolved is alt + arrow to move between word boundaries

[marcbachmann]

Umlauts are also still a problem. (alt + u (¨) + u, on US keyboard)
Here's how iTerm handles them. I have no idea how hterm manages to swallow those inputs.

[nfcampos]

@marcbachmann can you check if #214 fixes that for you?

[luiscobits]

I use alt + ñ to get: ~ but that not work
I'm latin american, so I use the letter Ñ to get ~

[mxstbr]

I can confirm that ALT + n on a german keyboard doesn't work to insert ~. Typing Umlauts directly (in this case ü) ends in this:

[petetnt]

Same issue with finnish keyboard layout and tildes, where ~ comes from alt+¨ (the key with ^ as shift+key).

[micimize]

Broke alt+ behavior for ;, h, j, k, z for me, so I reinstalled 0.5.0. Would be very good if rolling back an update was as seamless as installing one

[marcbachmann]

Broke alt+ behavior for ;, h, j, k, z for me, so I reinstalled 0.5.0. Would be very good if rolling back an update was as seamless as installing one

What's the expected behavior?

[micimize]

@marcbachmann they're mapped to various commands in tmux. alt+; = command line, alt+hjkl = pane switching, and alt+z = prefix

[mxstbr]

To elaborate, ~ wasn't working in 0.5 for me either, not sure about umlauts!

[suitupalex]

I'd also like to add that alt+1 or any of the layout command variants (2-5 and space) for tmux are also not being registered.

[Vistur]

Same issue with spanish keyboard: alt + ñ != ~

[kasperlewau]

Same deal for Swedish & Danish layouts on early 2015 MBP's. alt does not want to play ball.

[deepsweet]

having this in tmux config works fine in iTerm but not in Hyperterm:

# switch panes using Alt-arrow without prefix
bind -n M-Left select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up select-pane -U
bind -n M-Down select-pane -D

[benoitzohar]

Same issue with french keyboard: alt + n != ~

This is a deal breaker for me :/

(in version 0.7.1)

[whitelynx]

I think part of the problem has to do with how legacy terminals were implemented, and what capabilities a modern terminal emulator needs to... well, emulate. 😛

As mentioned in the XTerm Control Sequences documentation, the "Alt" key is often used to emulate the "Meta" key that is missing from most modern machines.

• On older 8-bit ASCII terminals, Alt would set the highest bit in the generated byte, allowing you to generate characters with ASCII codes in the 128-255 range, instead of the 0-127 range. (this is rather similar to Mac OS X's behavior of allowing you to type a different set of characters when holding Option/Alt, and similar to the "AltGr" key on international keyboards)
• Other terminals instead prefix each character with an Esc character (^[) when Alt is held down.

One big reason for terminals _not_ to interpret Alt+character sequences as alternate characters (AltGr behavior) is so that keyboard shortcuts using the Alt key can be bound in terminal programs. (see this article on the Vim wiki for several examples, and more information on the problem) On the other hand, that makes things more difficult for international users who rely on the ability to type certain characters with AltGr-style behavior.

If you're interested, I've collected some (currently rather incomplete) information about how various terminals handle different key combinations, and shared it in this spreadsheet. I'm planning on moving the data into a database, and having a terminal program that will ask the user to press certain keys in order to fill out information for different terminals.

---

It seems to me that the most sensible route for a terminal app to take is to provide user-configurable key bindings. (I've already wanted this in hyperterm, since I'm primarily a PC user, but now having to work in Mac OS X is driving my muscle memory insane; I'd _really_ like to remap some of the standard bindings hyperterm provides) I started working on a plugin to allow this, but so far I haven't had much luck even duplicating the built-in keybindings. If I get it working, I'll push it to GitHub and announce it here.

[beane]

I tend to use alt+b to navigate backwards between words, which in HyperTerm produces a funky ∫ character. I had the same issue when configuring iTerm, which was solved thanks to the option to map alt to +Esc. Would love to see that option in HyperTerm!

[beane]

Update: Just discovered how to bind Alt-b and Alt-d on OS X (and probably other Linux machines as well).

I added the following lines to my ~/.inputrc:

# `Alt-b` to nav back a word
"\xe2\x88\xab":"\eb"
# `Alt-d` to deleted back a word
"\xe2\x88\x82":"\ed"

You can also write

$ bind '"\xe2\x88\xab"':'"\eb"'
$ bind '"\xe2\x88\x82"':'"\ed"'

to temporarily have those bindings in any given session.

I think this will probably work on any terminal you're using, which is kind of cool, but it would still would be awesome to have a configurable option in HypterTerm!

Sources:

Helpful SO answer.
Script for finding what characters you need for binding from a surprisingly useful random 2005 internet page.

[whitelynx]

@beane That will work for bash, but not for some other shells or terminal apps. For instance, in fish, you'd have to use its bind command (which has a different syntax than readline's bind), and in Vim, you'd probably want to use CTRL-V in insert mode to get the right bindings. Screen and tmux (and therefore Byobu) use the bind-key command in their configs.

It'd still be easiest if HyperTerm had a way to configure its keybindings so we could set it up to produce keycodes that are expected by most terminal apps, instead of having to configure each one separately.

[molovo]

I have alt + shift + left/right mapped to switch windows in tmux, and this doesn't work in Hyperterm (but does in Terminal.app and iTerm). alt + left/right to move between words _does_ work though, so it's the shift modifier that breaks it.

@whitelynx +1 for configurable keybindings. Will resolve a lot of these issues fairly easily.

[agarrharr]

I think #686 will fix this issue.

[molovo]

@aharris88 You're right, I think it will. Thanks

[flybayer]

Can this be closed now?

[agarrharr]

I believe so. It works for me.

[ekmartin]

686 doesn't fix the tilde problem though, right?

[agarrharr]

I don't think so, but maybe #761 did.

[kevinSuttle]

I noticed ⌃⌥⇥ doesn't select panes, either, with or without ⇪.

[k1sul1]

Neither ~ or ^ work for me on MacOS Sierra. Finnish keyboard layout.

Combination for ~ is alt + ^, and combination for ^ is shift + ^.

Considering that shift and alt keys work just fine for other characters, I think this is an issue with the ^ key.

I can type capital letters and @ just fine for example. On MacOS @ is generated by pressing alt + 2

Picture of the keyboard for clarity:

Is there a proper workaround for this? I've been able to cope without ~ by using $HOME (pretty cumbersome but no pain, no gain), and I've somehow managed to survive in Vim without the ^ key, even if switching files between is not efficient.

Navigating with alt + ← works fine for me.

[rauchg]

This is already being addressed @k1sul1. Soon you'll get an update with the fix!

[winneon]

I'll be looking forward to that myself! I've been trying to use Hyper as my main terminal lately, but some of the small kinks like alt / option not acting as a meta key are really making life difficult.

[matheuss]

Closing since it was fixed via #1006 🙌

[iamjwc]

After the fix, I'm still having issues with navigating forward and backward by word boundaries. I added one more rule to @beane's suggestion of using ~/.inputrc to get moving forward by word boundaries working:

# `Alt-b` to nav back a word
"\xe2\x88\xab":"\eb"
# `Alt-d` to delete back a word
"\xe2\x88\x82":"\ed"
# `Alt-f` to nav forward a word
"\xc6\x92":"\ef"

[nwshane]

@deepsweet Did you discover a workaround to enable using the alt-key for tmux shortcuts in Hyper? I'm having this problem as well.

I use Alt-h/j/k/l to move between tmux panes, and I'm not able to use those shortcuts in Hyper, which makes it unusable for me. If anyone has advice on how to fix this issue, it'd be much appreciated.

[flybayer]

@nwshane Alt-h/j/k/l is working for me to switch tmux panes with modifierKeys: { altIsMeta: true } in .hyper.js and this tmux config.

[beane]

Is anybody else still having issues with alt-b or alt-f? They still produce ∫ and ƒ respectively.

Setting modifierKeys: { altIsMeta: true } didn't help.

The relevant iTerm config lets your map altto +Esc (whatever that means -- it seems to function like Meta and also Esc).

[whitelynx]

@beane: "+Esc" means that for example pressing Option+F will send Esc+f, or ^[f. This is probably what most people who use virtual terminals in X11 are used to. The "Meta" option should produce the Meta emulation behavior I described above (setting the 8th bit in the produced characters), and "Normal" should give you the standard MacOS behavior of typing extended characters.

[nwshane]

@flybayer I put modifierKeys: { altIsMeta: true } in .hyper.js, but alt-h/j/k/l still outputs special characters (instead of switching the tmux pane). Other ideas?

[beane]

@whitelynx good to know! I just want hyper to let me configure that 😭

[cbrwizard]

Putting modifierKeys: { altIsMeta: true } in .hyper.js helped make Alt work in neovim on my Mac, thanks!

[sebm]

This appears to have been reintroduced as of at least 2.1.1.

[flybayer]

Yes @sebm, I'm unable to use alt key bindings in Neovim.

[saamalik]

Does anyone know how to get alt+. to paste the last argument from the previous command? I tried modifierKeys: { altIsMeta: true } but this didn't work.

Using OSX.

[olealgoritme]

altIsMeta: true
vim: alt + arrow keys NOT working