This seems to be a bug in Vim's handling of 'langmap'
. I can consistently reproduce it and it seems to only happen when using a "from" character on the 'langmap'
that is outside of the basic 7-bit ASCII range (letters, numbers, basic symbols.)
I reported the issue upstream here:
https://github.com/vim/vim/issues/7458
(I'll update this answer once there's a fix for it.)
For now, as you reported in comments, adding specific mappings seems to be a functioning workaround:
nmap gü <Plug>(swap-prev)
nmap gó <Plug>(swap-next)
In the comments, you also asked about how the 'langmap'
interacts with commands such as f
, F
, t
and T
. For those, as well as r
(to replace a single character), the 'langmap'
settings are intentionally not used.
There's a separate :lmap
command (separate from the 'langmap'
settings) that allow you to create similar mappings to the ones from 'langmap'
, but that work in other situations, which include the f
, F
, t
and T
motions and the r
command.
But these also may affect the Ex command-line, the line when entering a search pattern (after /
or ?
) and they may also affect how the key behaves in Insert mode. There's a handful of additional settings to control those, and also key bindings such as CTRL-^
to switch the behavior in each of those modes. (Warning, the rabbit hole goes deep from here.) See :help language-mapping
for all the gory details (you'll need to read that carefully and probably experiment with it to find what works well in your case.)
set nolangremap
. I believe the default is on and disabling it might be the sane setting (from my reading of the help docs.)langmap
has it's limitation. E.g. I just found out that if I have alangmap
forŐ}
moving around the paragraphs work butfŐ
will not jump asf}
. This might actually be a good thing, still :)nmap gü <Plug>(swap-prev)
and ` nmap gó <Plug>(swap-next)`set langmap=[<
orset langmap=(<
it works correctly (withg[
org(
, resp.), butset langmap=é<
and usinggé
doesn't work for me (with a simplenmap g< gU_
for testing).