remapping i key

[ri-aje]

hi, I ran into this plugin which looks awesome, though I am having a hard time making it to work with my customized key layout. similar to https://github.com/wellle/targets.vim/issues/213, I am using colemak layout and with many vimrc remap to keep sane finger movements. I read through that post but cannot figure out something that works for me. hopefully you can help me out.

in my case I have

  noremap i l
  noremap u i

this is so to keep the original muscle memory with vim on standard layout. no matter what combination I try with

 let g:targets_aiAI = 'auAU'
 let g:targets_mapped_aiAI = 'aiAI'

targets i* text objects don't work. I traced the code and it looks like the new targets#e way mapping always failed because i has been noremapped, so the targets mapping simply don't get injected. I thought about breaking my mapping into inoremap and nnoremap, but that breaks the physical i key working as l in visual mode.

could you help me with my case? thanks.

currently only the legacy mapping works, but it looks like it's not maintained since I noticed it's already missing the q for any quote feature.

[wellle]

Hey! Can you try these settings?

noremap i l

inoremap u i
nnoremap u i

let g:targets_aiAI        = 'auAU'
let g:targets_mapped_aiAI = 'aiAI'

[ri-aje]

thanks. adopted a bit. looks like working now.

noremap i l
nnoremap u i
let g:targets_aiAI        = 'auAU'
let g:targets_mapped_aiAI = 'aiAI'

will try a few more days in case it introduces other issues.

[ri-aje]

thanks. adopted a bit. looks like working now.

noremap i l
nnoremap u i
let g:targets_aiAI        = 'auAU'
let g:targets_mapped_aiAI = 'aiAI'

will try a few more days in case it introduces other issues.

just found builtin vip (physical keys vur, r is remapped to p per colemak) is now broken. on a second thought, this makes sense since u isn't mapped to i in visual mode anymore.

[ri-aje]

thanks. adopted a bit. looks like working now.

noremap i l
nnoremap u i
let g:targets_aiAI        = 'auAU'
let g:targets_mapped_aiAI = 'aiAI'

will try a few more days in case it introduces other issues.

just found builtin vip (physical keys vur, r is remapped to p per colemak) is now broken. on a second thought, this makes sense since u isn't mapped to i in visual mode anymore.

@wellle any other suggestions? thanks.

[wellle]

Hmm. I tried a few things but didn't get anything working.

But then I disabled targets.vim and put only these mappings in my vimrc:

noremap u i
noremap r p

But even then typing vur didn't work as vip. So maybe this is not even related to this targets.vim?

[ri-aje]

Hmm. I tried a few things but didn't get anything working.

But then I disabled targets.vim and put only these mappings in my vimrc:

noremap u i
noremap r p

But even then typing vur didn't work as vip. So maybe this is not even related to this targets.vim?

@wellle if you try vup (physical keys vup so it's clear what you should press), does it work? sorry sometimes this is pretty confusing with several levels of mapping. it feels like after vi vim is in a mode where no mappings count anymore, so pressing r gives no p, and I have to press the plain p key to have vim receive it correctly. I said r earlier because that's my p key, recall that my keyboard layout is colemak, I should have translated it back to querty equivalent for comm. it almost feels like vim has an unknown mode that is not affected by any of the *map features. thanks.

[wellle]

Yes exactly. So maybe you want to open a Vim/Neovim issue about that?

[ri-aje]

Yes exactly. So maybe you want to open a Vim/Neovim issue about that?

how do I do that for vim? and still, nnoremap u i results in no u->i mapping in visual mode, which will break all inner text objects in visual mode. I guess that means no way to resolve the conflict?

[wellle]

how do I do that for vim?

You can open an issue here: https://github.com/vim/vim/issues

and still, nnoremap u i results in no u->i mapping in visual mode, which will break all inner text objects in visual mode. I guess that means no way to resolve the conflict?

Very interesting! I can only confirm. I couldn't get it to work. Even though targets#e() returns ip (it's an expression mapping), so it should select the inner paragraph. I tried all possible combinations, so regardless of whether it returns ip, up, ir or ur, it never selects the paragraph. 🤔

[infokiller]

Yes exactly. So maybe you want to open a Vim/Neovim issue about that?

how do I do that for vim? and still, nnoremap u i results in no u->i mapping in visual mode, which will break all inner text objects in visual mode. I guess that means no way to resolve the conflict?

This is expected: nnoremap only affects normal mode. Use xnoremap or noremap to also affect visual mode.

[infokiller]

Hmm. I tried a few things but didn't get anything working.

But then I disabled targets.vim and put only these mappings in my vimrc:

noremap u i
noremap r p

But even then typing vur didn't work as vip. So maybe this is not even related to this targets.vim?

Works for me in both vim and neovim. Try the following in a shell:

vim -u /dev/null -c 'noremap u i' -c 'call feedkeys("vup", "mt")' <(echo 'aaa\n\nbbb')

You should end up with the "aaa" line selected.

[ri-aje]

Hmm. I tried a few things but didn't get anything working. But then I disabled targets.vim and put only these mappings in my vimrc:

noremap u i
noremap r p

But even then typing vur didn't work as vip. So maybe this is not even related to this targets.vim?

Works for me in both vim and neovim. Try the following in a shell:

vim -u /dev/null -c 'noremap u i' -c 'call feedkeys("vup", "mt")' <(echo 'aaa\n\nbbb')

You should end up with the "aaa" line selected.

did vur also work for you?

[infokiller]

No, xnoremap r p doesn't work for some reason, though xnoremap r w works and possibly other text objects.

[ri-aje]

No, xnoremap r p doesn't work for some reason, though xnoremap r w works and possibly other text objects.

I cannot repro. for me, neither noremap r p nor noremap r w worked. this isn't ideal but at least consistent. not sure why would xnoremap r w works for you, but not xnoremap r p.

as far as I can tell, once v key is pressed, both ur should be subject to visual mode mapping. the reality is u is while r appears not, which is somewhat unexpected. I asked in vim_use group, but so far got no explanation after a few days. I posted on vim git repo again and hopefully will get some good explanations.

[glm4610]

I think I've managed to find a workaround for this!

Original Problem

Let's say you want to swap two keys by doing

noremap k i
noremap i k
" unmapping for targets.vim to work
ounmap k
let g:targets_aiAI        = 'akAI'
let g:targets_mapped_aiAI = 'aiAI'

Expected behaviour

All we want is for our k input to work just like VIM's i in the case we don't use one of target.vim's bindings.

The problem

When the user presses dkw, targets figures out it isn't supposed to mess with that and returns diw to VIM (or whatever key is configured in targets_mapped_aiAI). The problem here is that i is mapped to k in noremap i k. And, since targets.vim uses a recursive mapping, VIM expands diw -> dkw. Which, in this case, would lead to VIM deleting two whole lines upwards (and then moving forwards one word).

However, targets.vim is smart and expects g:targets_mapped_aiAI to be a list, not necessarily a string. Which led me to...

The workaround

noremap k i
noremap i k

" unmapping for targets.vim to work its magic
ounmap k 

let g:targets_aiAI = 'akAI'

" We use targets.vim's own internal trick and make it return a fake key sequence
let g:targets_mapped_aiAI = [ 'a', '@(proxy_i)', 'A', 'I' ]

" Now when targets returns the mapped key sequence, it will be bound to VIM's original i key
noremap @(proxy_i) i

Now when the user presses dkw, the mappings go as follows:

(user) --> (targets.vim) --> VIM
 dkw   --> d@(proxy_i)w  --> diw

And everything works as planned. Crisis averted (for now) :rocket:

[ri-aje]

thanks @glm4610 for taking a look at it. looks like it's been quite awhile since I posted, and I have moved onto other plugins with similar functionalities. I did give your workaround a brief try, but it doesn't feel like it's quite working. I couldn't recall what was my targets.vim experience a few years back, so I cannot tell if your workaround makes it better. I didn't debug it further since it doesn't seem worth it at this point. in any event, thanks for your attention and sharing your findings.