-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed macOS alt-keys not working (see issue #49) #71
Conversation
function s:MoveKey(key) | ||
" If on macOS, use the equivalent key for <A-KEY> | ||
if has('macunix') && g:move_key_modifier_visualmode == 'A' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about the performance impact of the has(…)
. But I will accept it for now.
I do not have a Mac to test, so maybe @alex-popov-tech could have a look and close #49 if fixed? |
@matze done, thank you |
I'm on a Mac (Monterey, version 12.4) and and this plugin has been working perfectly for years, but it seems to have stopped working after this PR merged. When I comment out all the additions from this PR it goes back to working again. |
Hmm that's weird. Are you using iTerm? Maybe it's a terminal emulator problem. If so we can use the |
I am and it does seem to be an iTerm specific problem. Just tested it with the default terminal app, as well as kitty and alacrity and the plugin works as is (without me commenting out the diff from this PR). |
I'm using iTerm as well, so this is definitely strange. I'm on the same macOS version as you as well. I'll do some more research, but I'm really not sure what we can do to fix this because I don't know what the problem is. |
same thing here, I'm using Big Sur and iTerm and suddenly it doesn't work properly after these PRs are merged too. I also tried it with |
Here is my iTerm profile exported as JSON w/ all the color related stuff removed (made this way too long): Notably there seems to be a
Also, found this setting in experimental features (see picture), but I don't have it turned on. Seems like another option that could potentially affect this. |
Hi @BStephenBB, yes, I have the Here's the chunks of related to the key for "Option Key ..." {
// ...
"Option Key Sends" : 2,
"Right Option Key Sends" : 2,
"Right Option Key Changeable" : true,
// ...
} I'm not sure what the |
Here are my settings related to the option key: {
"Option Key Sends" : 0,
"Right Option Key Sends" : 0,
"Right Option Key Changeable" : true,
} After poking around these settings I think they are the problem. These settings are located under Profile->Keys. If we can find a way to temporarily change this setting for the user in the plugin, we could fix this issue. I have the Update: echo "\e[?1036h" This worked for me, even though my option key sends 0. I entered Vim and and behaved the same way your terminals do. If we can trigger this within Vim we could set the proper behavior for the user. Unfortunately I had to turn on the DECSET 1036 setting to get this to work, but since that setting is in experimental mode, it might be automatically set in a future release of iTerm2. |
My 2¢: I think we should figure out what will work for default "stock" iTerm and make If it's too hard to make |
I agree. I'm not sure what to keep as the default though. I never messed with the option key for my iTerm settings, so I think We should definitely include a note about this in the README and include an option for this. |
I've noticed |
I made another pr (#72) about this issue. We might need more discussion about this, but I thought I should at least get a working version up in the air for now. |
FYI, after this PR, this is what works for me: #69 (comment) |
Issue
vim-move would not work on macOS due to the operating system's incompatibility with the
A
key mapping modifier.Fix
The plugin detects if the user's system is macOS and maps the keys accordingly.