Keyboard layout "U.S. International PC' is not handled correclty

[ecerulm]

I have "U.S. International PC" as Keyboard Input Source which means that to produce ä I need to press " followed by a and to produce an actual double quote I have press " followed by space.

To go to a mark like '> I can press '<space>> in vim inside iTerm (terminal emulator) and works fine. When I try the same thing in MacVim it doesn't work. MacVim doesn't seem to recognize this while in normal / operator pending mode,

So '<space>> seems to be interpreted (not sure) as :

1. jump to mark called <space>
2. then indent.

but it it should be interpreted as "jump to end of last visual selection"

If I type just '>seems to be interpreted as nothing. But the right sequence to type would be '<space>>.

Anyway MacVIm doesn seem to be usable with U.S International PC layout, while vim in iTerm works fine.

[eirnym]

If you open on-screen keyboard in OS X, you'll see these two symbols (` and ') are not the same as others. They are used to enter sybmols like á without requirement of holding a button or using an option key. Because of this handling, OS X generates different input sequence to an application while using these keys.

Terminal's input is a text-based, when MacVim (GUI) not in Insert or Replace modes, the input is keypress-based, and it swallowed by OS X.

Try to change a layout to US and check if '> works there. To insert symbols from extended alphabet you can press and hold a button and then select required from a pop-up selection.

[ecerulm]

Changing to US instead of US International work but it's not really an option for many (for those of us that write in several languages like spanish, english and swedish and don't want to switch to different layout every time).

I wonder if it will be possible to handle the input an at different level letting macOS handle the dead key like iTerm does.

[eirnym]

MacVim uses NSTextView as a base and doesn't handle keyboard input as PTY does (e.g. in iTerm/Terminal). To rewrite this core components it would be too much effort to be involved than use compatible keyboard layout.

PS: I use Polish layout (Polski pro) for most of my input and completely fine with it.
PPS: Looked on a few more European keyboard layouts and saw that most usable keys are accessable directly or with modifiers like Shift or Option

[eirnym]

@ecerulm Does it still an issue for you?

[ecerulm]

well, yes, I stopped using macvim (and VimR) because of this. I know I can use Swedish Pro , as you say most of the keys are accessible via modifiers. But I choose long time ago to go the International Dead keys way, I can't go back anymore. I just use vim in the terminal.

I understand that maybe dead keys layout are not that common and maybe you want to close this as WONTFIX.

[eirnym]

I think it's unsolvable right now because we use NSTextView as for a render and key handling. But it could be changed in the future, who knows.

[bighi]

I just found this issue. I am using MacVim and it makes me sad. I don't know what NSTextView is, but every other Mac app handles dead keys perfectly, MacVim is the only one with a problem. So it makes me guess it's MacVim doing something wrong, not the text thing provided by Apple.

I could help debug it if needed. But I would relaly like to see this issue fixed. It's the only thing preventing me from using MacVim (and many others, since everyone on my company alerted me not to try).

[eirnym]

@bighi You're welcome to help.

AFAIK not every single application has fixed such issues and not many applications in macOS are really using ALT/Meta/Option keybindings by default at all. For example, there's a problem for Visual Studio Code (and other Electron-based apps), IntelliJ Idea (and other java apps) where the problem is quite the opposite. Currently I doesn't see any such bindings (Option-letter) in the recent versions of IntelliJ products.

macOS has both option keys behave as AltGr in Windows and Linux (and there you have Alt and AltGr separated), so you have to catch these keys in a special way and then put them into event queue for Vim.

PS: I personally using Polski Pro without any headache. All keybindings with alt I use, I've re-binded and I'd like to keep current behavior for myself when possible.

[bighi]

Sure, I'm happy to help however I can.

But maybe there's a misunderstanding. OP was not talking about ALT/Meta/Option at all.

It's just that for example, while using US International, pressing ' and then a results in á in every other app, except MacVim. And there are many other combinations.

In the US International layout, some keys become dead keys. When pressed, they do nothing until you press a second key. And then one single character is inserted, despite the fact that the user pressed two keys. And some keys like ' and " are dead keys.

The problem is that in MacVim, dead keys doesn't work. They insert a character as soon as the first key is pressed. So in MacVim I can't write áor ò. And single quotes like ' behave in unexpected ways.

[eirnym]

I have MacVim 161 and macOS 10.15 and typed Option-u-u to have ü (¨+ u). if first or second key is bonded to a specific action, you'll never get the right result. This is how Vim core works, it doesn't know what'll be next and it's hard to predict it.

[eirnym]

AFAIK usually editors doesn't have key-bindings for letters or alt-letters in macOS

[bighi]

This is not how Vim core works. Or maybe there's still a misunderstanding (on your part or mine).

In vim (terminal vim in Mac and Linux, and also gVim in Linux) I can use all the keybindings bound to ' (like jumping to marks) just fine, even though it's a dead key in this keyboard layout.

Just to make sure we're on the same page, we're not talking about Option-u. With dead keys, it would be " + u to insert ü.

I can even use ' as a binding in the insert mode, without losing the option to write á. That's because the ' is only actually inserted if I press ' and then <space>. Before I press space (or any other second key), the quote character is shown in a smaller font (or some other visual hint), to indicate it's waiting for the second keypress.

Except in MacVim.

I hope I could explain it better this time.

[eirnym]

first, you have to be sure, that this symbols are present in the font you type or exception ranges to type in another font

with Alt there's many hacks here and in many other lines in this file (mostly) to threat this as alt, not as special key