<A-n> fails to interprets in Macos. I set neovide_input_macos_alt_is_meta

[OliverChao]

In Macos, I set vim.g.neovide_input_macos_alt_is_meta = true, keys works fine except .

I don't know if someone can reproduce it. But other keys like and are ok.

To Reproduce
can not be matched.

Expected behavior

Screenshots

Screen.Recording.2023-05-16.at.12.42.15.mov

If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: 13.3.1 (a) (22E772610a)
• Neovide Version 0.10.4
• Neovim Version 0.9.0

Please run neovide --log and paste the contents of the .log file created in the current directory here:

Additional context
Add any other context about the problem here.

[richmeta]

I also have this too.

In neovide:

:map <a-n>
No mapping found

:map <a-n> :echo "hello"<cr>
Pressing <a-n> - nothing happens

But
:map <a-m> :echo "hello"<cr>
and <a-m> works as expected

I even tried with <m-n> which doesn't work either.

neovide 0.10.4
NVIM v0.8.2

[fredizzimo]

Could you try the latest master version, the keyboard handling was changed a lot here #1789

[OliverChao]

Could you try the latest master version, the keyboard handling was changed a lot here #1789

Thanks for your reply. However, there also some errors for converting mappings.
I write <C-v> then <A-h> and it prints <M->`.
Here are some conversions:

<A-n > --> <M-n>  right
<A-m> --> <M-µ>
<A-i> --> <M-i>  right
<A-p> --> <M-π>
<A-h> --> <M-˙>
<A-l> --> <M-¬>

[fredizzimo]

This should be fixed by #1899, it would be great if you can test that.

[OliverChao]

Thanks for your work. Sorry to say that it some errors exists.
The mappings #1789 works, #1899 fails, and vice versa.

<A-n> and <A-i> fail to map <M-n> and <M-i>.
<A-m> maps <M-m> successfully.

I think that is because some keymaps(like <Option-n> and <Option-i>) have special functions in MacOS input method.

[fredizzimo]

I think we will leave the fix out of #1899 for now. And then once this rust-windowing/winit#2887 gets merged try to use that instead. That should also allow setting the option for the left and right alt separately.

[saikete]

thanks for your work！
I noticed that he has been merged，so How can I set the left and right alt keys separately?

[fredizzimo]

We need to wait until #1899 is merged. Then someone, preferably someone that actually owns a macos computer, needs to implement it.

I don't want to include the fixes and modify #1899 anymore, since it's ready for merging as it is, especially since I can't test anything myself.

[saikete]

I can help with fix testing, but implementation specifics I may not be able to, I'm not very familiar with rust,,

[mgax]

This should be fixed by #1899, it would be great if you can test that.

@fredizzimo with the following setup:

vim.g.neovide_input_macos_alt_is_meta = true
vim.keymap.set("n", "<a-n>", ':echo "hello n"<cr>')
vim.keymap.set("n", "<a-m>", ':echo "hello m"<cr>')
vim.keymap.set("n", "<a-o>", ':echo "hello o"<cr>')

On the current main (bc94189), both "hello n" and "hello m" are printed, but not "hello o".
On #1899 (340571b), only "hello o" is printed.
I suspect this is related to my keymap, where alt-n and alt-m are dead keys, but not alt-o. Indeed, with another keymap, where alt-m is not a dead key, the pattern holds, "hello m" works on #1899 but not on master.

[fredizzimo]

I think this can be fixed by integrating rust-windowing/winit#2887, which does the swapping at a much lower level, but I'm not completely sure.

[JamesWidman]

@OliverChao @richmeta This appears to be fixed by #2046; please let us know how it goes!

[richmeta]

Hey @JamesWidman - i've just tried it with a clean build from your repo.

Re-running using the same test as I posted earlier, unfortunately <a-n> is still not working here ( and <a-m> does ).

NVIM v0.9.1
rustc 1.72.1 (d5c2e9c34 2023-09-13)
cargo 1.72.1 (103a7ff2e 2023-08-15)
OS MacOS Ventura 13.1

I'm interested if i can help in some debugging of this issue, so I'll spend some time on this later.

Thanks for your help!

[JamesWidman]

@richmeta from the top-level directory of the neovide repo, i tried putting your setup into a file named c.lua and ran:

target/debug/neovide -- -u c.lua

...and the key bindings work for me in this case.

Are you setting vim.g.neovide_input_macos_alt_is_meta = true after startup? If so, note the "breaking change" note in the first post of PR #2046, and the workaround.

(We might be able to avoid that breaking change, but I'm waiting for feedback on that point.)

Thanks for your help!

You're welcome! And thank you for testing!

[richmeta]

@JamesWidman - yes my config already has neovide_input_macos_alt_is_meta = true. I added neovide_input_macos_option_key_is_meta = "Both" too.

Running as you suggested gives me both "hello m" and "hello o" but "hello n" gives no output.

What's interesting is that <m-n> seems to swallow the next key mapping, so if I do <m-n><m-m> there is no output. same with <m-n><m-o>. <m-m><m-o> works as expected, printing both. Even <m-n>a does not put me in insert mode, but ... <m-n>i does! Weird.

I'm on a UK keyboard map here, and I use an external physical keyboard (Alt maps to Option). However pysically unplugging and directly using the mac keyboard makes no change to the test.

[mgax]

What's interesting is that <m-n> seems to swallow the next key mapping, so if I do <m-n><m-m> there is no output. same with <m-n><m-o>. <m-m><m-o> works as expected, printing both. Even <m-n>a does not put me in insert mode, but ... <m-n>i does! Weird.

I'm on a UK keyboard map here

Yep, the Mac UK keyboard layout has option-n as a "dead key"; it temporarily types a ~, which you can follow up with e.g. a regular "n", to produce ñ. option-m though produces a single character, µ, so not a dead key.

[fredizzimo]

If I remember correctly, the dead keys are delivered using the IME system on the mac. So it's likely that the ime system handles it completely, and therefore nothing is delivered to Neovide.

You can try disabling IME https://neovide.dev/configuration.html#ime
vim.g.neovide_input_ime = false

[richmeta]

Awesome!

Yes setting vim.g.neovide_input_ime = false fixed <m-n> for me. Now working as expected. Thanks! 🙂

[JamesWidman]

Yes setting vim.g.neovide_input_ime = false fixed <m-n> for me. Now working as expected.

Oh, weird...
So here's what I've tried:

With vim.g.neovide_input_ime unset, (which, internally, neovide defaults it to true), and with all three of the following english input sources:

• U.S.
• British - PC
• British

("System Setings" -> "Keyboard" -> "Text Input")
...and with an option key that is not mapped to meta using vim.g.neovide_input_macos_option_key_is_meta = "OnlyLeft" and then using the right-option + n followed by n, I observe the dead-key behavior that @mgax described. And when i use the left option key (which maps to meta), all three of @richmeta's keymaps work for me.

(Also, this shouldn't make a difference, but I also set vim.g.neovide_input_ime = true in the startup file and got the same results.)

@richmeta, if you run neovide with:

target/debug/neovide -- -u c.lua

(with the c.lua described above)
...and enter insert mode and type:

control v
meta n

(with whatever physical option key you have mapped to meta)
...what characters are inserted?

[richmeta]

Pressing <c-v><m-n> doesn't actually print out any character - it's still waiting for input.

If I then press n
then it prints out ñ

With vim.g.neovide_input_macos_option_key_is_meta = "OnlyLeft" (previously "Both") and then doing the same with the right meta has the same effect too.

edit: my input source is "British - PC"

[JamesWidman]

very werid...
ok, so to sum up for anyone else who wants to test this:
with this c.lua:

vim.g.neovide_input_macos_option_key_is_meta = "Both"
vim.g.neovide_input_ime = true

(keymaps are sort of unnecessary for this test)
...and with neovide invoked with the command:

$ pwd
/path/to/clone/of/neovide
$ target/debug/neovide -- --clean -u c.lua

...and under the British input source*, i enter insert mode and type:
control v
option n

Expected/desried result (which is the result that I observe): nvim inserts the string "<M-n>" into the buffer.

@richmeta's result: nvim waits for input, and if you then input another n, nvim inserts ñ

(This suggests to me that, on @richmeta's machine, there is maybe some part of winit that is not treating the option key as "alt" (as it should under this configuration).)

@richmeta, I think we shouldn't merge PR #2046 before we reproduce the behavior that you see, because there will probably be other users who see the same behavior, and I don't want to tell them to disable dead keys.

At the moment I'm stumped. If anyone else would like to suggest steps to reproduce the behavior that @richmeta sees, please let me know!

---

edit: updated shell command to include the --clean option per @fredizzimo's suggestion

---

edit 2: I also tried this with the input source "British - PC" and got the same result as with "British"

[fredizzimo]

I suggest adding --clean to the command as well so, otherwise it may in some cases load existing plugins.
target/debug/neovide -- --clean -u c.lua

[JamesWidman]

@richmeta if you want, you could try inspecting winit's behavior in a debugger session—specifically, a part of winit that was introduced to implement the OptionAsAlt behavior:

With the test case above, after control v but before option n, pause execution (which, if you're using LLDB in a terminal emulator, you can do this with ctrl + c) and add/enable a breakpoint in replace_event() (in winit-0.29.0-beta.0/src/platform_impl/macos/view.rs); then continue execution, switch back to neovide, and enter option n, and the debugger should break in replace_event().

As you step through, here's what's supposed to happen (and what you should definitely observe in the case of option m and option o):

• option_as_alt should have the value Both
• ignore_alt_characters should evaluate to true
• we reach the call to NSEvent::keyEventWithType

if you step into NSEvent::keyEventWithType, you may find an interesting difference between (1) parameter values that you get for option n and (2) parameter values that you get for option o.

(this debugging experience is somewhat complicated by the fact that LLDB doesn't know about rust, so it treats rust expressions as if they were C or C++ expressions (which can work, e.g. if you need to display a string, so you cast it to (char*)), and in this context the clang parser may be given identifiers that are modified from how they appeared in the source code. Maybe I should see what the rust-debugging situation is like in VScode...)

[richmeta]

Thanks @JamesWidman - I'll see if i can find some time this week to investigate more thoroughly.

Meanwhile, i have a question: Why do we need IME on for mappings?

Are we saying it would be possible for someone to do for example?
map <m-ñ>e :echo "e"<cr>

Does neovim itself allow this mapping?

And the actual keypress required for IME users would be alt+n+n+e . (and I don't know what for non-IME users).

Depending if their OS supported IME or not i think would be a bit confusing here?

[fredizzimo]

Are we saying it would be possible for someone to do for example? map <m-ñ>e :echo "e"<cr>

Does neovim itself allow this mapping?

Yes, that is actually supported and even required by the default mappings. On some keyboards like mine for example ` is a dead key, so I would not be able to jump to the exact location of a mark with the default mappings if dead keys would not work. Other dead keys used in the default mappings are ^ and ~. There are no default mappings that actually combine a dead key and a character like ñ, but they can be mapped, and even combined with modifiers. Neovim itself has no problems with any of those combinations, but the winit library does not report all combinations correctly, so not every combination will work in practice on all systems.

Furthermore, there's no difference between mappings and text input in Neovim, and the way that we communicate it, so we always have to assume that the user is typing text and send the keypresses according to that.

Note, that only macOS and in some cases the IME on other systems sends the dead keys through IME. On the other platforms they are sent as a regular input.

It's also possible to disable IME in only normal mode for example, and that is described here https://neovide.dev/configuration.html#ime

[richmeta]

Hi @JamesWidman,

Ok this is interesting. 🙂

I start debug with this:
lldb target/debug/neovide -- -- --clean -u c.lua

and I check vim.g.neovide_input_macos_alt_is_meta == true.

With <c-v><m-m> I get

(lldb) p option_as_alt
(winit::platform::macos::OptionAsAlt) $0 = None

and consequentially

(lldb) p ignore_alt_characters
(bool) $1 = false

so NSEvent::keyEventWithType() is not called

(lldb) c
Process 56444 resuming

note: this happens twice because replace_event() breaks twice - i checked the variables and they are the same in both cases.

After this <M-m> is shown in the buffer.

Trying with <c-v><m-n> has the same variable values, and the buffer shows as above in my screenshot - i can see neovide is still waiting for input, so then pressed n (and after two more replace_event's) i see ñ in the buffer.

I've also tried explicitly setting vim.g.neovide_input_macos_option_key_is_meta = "Both" but the outcome/variables are the same.

I finally tried with vim.g.neovide_input_ime = false, this time when <c-v><m-n> again option_as_alt == None and ignore_alt_characters == false, but this time <M-n> is output in the buffer without needing a second key press.

( I'm now using vim.g.neovide_input_ime = false in my main config and this works for me on vanilla neovide ).

[9mm]

Hey @fredizzimo i was curious which was still on this, was there anything to test?

[OliverChao]

In macos Sonoam Version 14.1 (Apple M2), all things work fine for me with the latest commits.
I build neovide from source.

I will close this issue, and if anyone has the same problem, you can reopen it or create one new issue.

[fredizzimo]

We never resolved the IME issues that were reported on some systems a few messages up. On some systems you might have to set vim.g.neovide_input_ime = false, for some of the mappings, but note that this also disables the dead keys.

@JamesWidman, has been busy lately, but #2046, which just needs some minor updates should fix a few other issues.

[OliverChao]

Yes. On MacOS(M2), mapping errors are gone without IME .
It seems that neovide fails to fix the IME problems. So I reopen it.

#2046 maybe help and I am waiting for it.

Fortunately, I use all alt mappings in normal mode.
So, I add some autocmds currently.

  vim.api.nvim_create_autocmd("InsertEnter", {
    callback = function()
      vim.g.neovide_input_ime = true
    end,
  })
  vim.api.nvim_create_autocmd("InsertLeave", {
    callback = function()
      vim.g.neovide_input_ime = false
    end,
  })

[CapSel]

I've got neovide 0.13.1 and none of the settings work for me - I can't get <M-1> and similar to work at all.
Funny thing is that these mappings work in neovim started in kitty.

In insert mode character Ńis inserted when I press OPT+1.