3.0.1 last update: lost backslash \ (Japanese layout keyboards)

Thanks for filing an issue! Please answer the questions below so I can help you.

• iTerm2 version: 3.0.1 latest
• OS version: MacOS X 10.11.5
• Attach ~/Library/Preferences/com.googlecode.iterm2.plist here (drag-drop from finder into this window) com.googlecode.iterm2.plist
• Attach a debug log, if possible. Instructions at https://iterm2.com/debuglog debuglog.txt
• Are you reporting a performance issue? Please attach a sample. Instructions at https://gitlab.com/gnachman/iterm2/wikis/HowToSample

Detailed steps to reproduce the problem:

1. Open iTerm2
2. Hold Alt and press the [¥/|] key on a Japanese keyboard (the Mac's one, or an external one as well)
3. Expected output: , actual output:

What should have happened: a backslash character ( \ ) appears on screen.

What happened: interestingly, I noticed multiple behaviours:

• in tmux: it outputs the yen character ( ¥ ), which is the key's expected output when no modifier is depressed
• in a simple bash prompt, it outputs an unknown character, that I pasted here: �
• but when debug log was active, and tmux running, it output nothing at all instead

Old behaviour on 3.0.0: the same key [¥/|] outputs a backslash whenever Alt modifier is depressed or not. It is thus impossible to output the expect ¥ character. I guess this behaviour is a bug too, but a lot harmless (I use \ a lot more than ¥ in a terminal context).

I'm pretty sure this change happened very recently, as I'm programming every day on this setup and make a fair use of the backslash key.

---

Here's a picture of a Japanese keyboard. My problem is with the key located left to the backspace key.

---

Temporary fix: define a key mapping in iTerm that maps Alt+¥ to "send text", value: \

Thank you for this report. A few questions:

1. What does Terminal.app do?
2. I see a backslash character to between ? and shift. Is that non-standard, doesn't work, or inconvenient?

Some background on this issue: There was some code that looked obviously wrong in the keyboard handler that replaced 0xa5 with \. It affected all keyboard layouts, not just Japanese. It was incompatible with some recent changes to improve UTF-8 support in tmux, and I couldn't find any history on it. So I'm trying to figure out how important this is for Japanese users to decide whether to make it the default behavior again.

For my future reference: from Wikipedia:

Keyboards designed for Japanese may have…the character ¥ (Japanese yen or Chinese yuan currency symbol) instead of \ (backslash, which may be replaced by the former in some typefaces and codepages).

I looked into the debug log and maybe the issue is not what I expected. It looks like the option key is bound to the esc+ action. In that case, it should do esc¥.

I guess esc+¥ is not very useful, so maybe the bet fix is to add an exception where Option+\ never becomes esc+¥, and let people add a keybinding to get out of that.

The following notes are for my future benefit:

Taking a look at the debug log I see this:

1465541904.706561 PTYSession.m:4583 (-[PTYSession keyDown:]): event:NSEvent: type=KeyDown loc=(0,477) time=103943.2 flags=0x80120 win=0x7fd5786432b0 winNum=3667 ctxt=0x0 chars="\" unmodchars="¥" repeat=0 keyCode=93 (80120+5d)[\][¥]:5c(\) <0>

Option-Yen is interpreted as a backslash by the OS. Good!

1465541904.706573 PTYSession.m:4950 (-[PTYSession keyDown:]): PTYSession keyDown opt + key -> modkey

Option is set to a non-default action.

1465541904.708075 PTYSession.m:1614 (-[PTYSession writeTaskImpl:encoding:forceEncoding:canBroadcast:]): Write byte 0x1b ()
1465541904.708981 PTYSession.m:1614 (-[PTYSession writeTaskImpl:encoding:forceEncoding:canBroadcast:]): Write byte 0xc2 (Â)
1465541904.708985 PTYSession.m:1614 (-[PTYSession writeTaskImpl:encoding:forceEncoding:canBroadcast:]): Write byte 0xa5 (¥)

Option+¥ becomes esc+¥.

Please try tomorrow's nightly build (iterm2.com/nightly/latest) and let me know if it fixes the issue for you.

Milestone changed to %3.0.1

1. In Terminal.app, I get the following:

• press the ¥| key alone => get a \ (note that in other applications, I get a ¥ character instead)
• press shift + ¥| => get a |
• press alt + ¥| => get a \
• press \_ (external keyboard) alone => get a _
• press shift + \_ (external keyboard) alone => get a _
• press alt + \_ (external keyboard) alone => get a "compose" `

2. Even though my external keyboard has that backslash key between ? and right shift, my Mac (with a Japanese keyboard too) doesn't. And I didn't find a way for that key to output a \ (see above).
3. I indeed set my left and right alt/option keys to act as +Esc in iTerm's settings, is that an issue?

Will try next nightly build soon. :)

Now it seems likely that iTerm's original behavior was intentional; it's just the comment in the code that was misleading. I should probably revert that change.

Please note that the behaviour in Terminal.app detailed above was identical to iTerm (even with option alt acts as +Esc enabled), up to the latest release that changed that and removed any way to get a \ when that alt option is enabled.

Yen support was reinstated a while ago in commit 4dd16e39. Sorry I forgot to update the issue.

closed