Make i18n support a setting

[kevinsawicki]

Several keybindings are currently unusable since Mac OS X maps them to multi-keystroke accents.

Such as:

• alt-n followed by an a types an ã
• alt-e followed by an e types an é.

This is useful if you are typing these characters but also makes the alt-e and alt-n keybindings unusable in a keymap since they generate the same key event alt-å and you can't distinguish between two in code. Type alt-n in the editor with the keybindings-resolver open to see for yourself.

One possible fix for this is to set type password on the hidden input since these characters can't be typed into password fields in this manner and so the key events go back to "normal" and alt-e and alt-n can now be used again in keymaps.

This PR adds a preference editor.enableI18nSupport that toggles the hidden input between text and password.

Other ideas/approaches are welcome, this is just an initial stab at it after @benburkert reported not being able to use alt-n in his keymaps file.

[kevinsawicki]

This will also affect being able to use:

• alt-u
• alt-i

[kevinsawicki]

Also, when this is disabled you will now be able to hold down a key to type is repeatably.

[nathansobo]

and also remove the ability?

[kevinsawicki]

Actually it will allow that ability, fixed the working, thanks.

[nathansobo]

Ugh. My bad diff reading continues. I didn't read it all the way through. I'll get better at this.

[kevinsawicki]

No worries, it was definitely missing a word or two so thanks for the feedback.

[probablycorey]

Just for some background on how other editors handle this (it looks like xcode handles it best.)

alt-e enters é

• Sublime
• Textmate
• Xcode
• MacVim

alt-e can be used as a custom keybinding

• Sublime
• Textmate
• Xcode
• MacVim

[nathansobo]

@joshaber Do you know how Xcode could allow alt-e to enter the ´ character but also allow alt-e keybindings?

[joshaber]

Xcode almost certainly has some custom event dispatching for its key equivalents since they're customizable.

I'm not terribly sure what that means for you guys. In the context of a standard Cocoa app, this means they have a custom NSApplication subclass which implements -sendEvent:. (Or they could be using the newer +[NSEvent addLocalMonitorForEventsMatchingMask:handler:].)

[nathansobo]

@zcbenz Do you think there's any way we could add a method to Atom shell to disable international character composition for specific alt- bindings by using the technique described above?

[probablycorey]

It would get more confusing because we only want to disable international character support if there is a key binding that uses it. This means things would have to be handled on the atom side instead of on the atom-shell side.

[nathansobo]

I would like the keymap to have a shot at handling all keydown events. Ideally, we receive the alt-e event and choose whether to process them or not. If we choose not to, then the international character composition continues to work as normal.

[kevinsawicki]

I'm going to close this out, we can always revisit.