Langmap

[Opisek]

While Vim for CM6 already supports simple map and unmap directives, it lacks the ability to interpret Vim's langmaps.

The purpose of a langmap is to allow typing in insert and replace mode using one's preferred keyboard layout, while still being able to use standard Vim mappings in normal and visual mode. This is crucial for people using other scripts like Greek and Cyrillic or using a different keyboard layout that would spread default bindings throughout the whole keyboard.

Example langmap for Greek:

ΑA,ΒB,ΨC,ΔD,ΕE,ΦF,ΓG,ΗH,ΙI,ΞJ,ΚK,ΛL,ΜM,ΝN,ΟO,ΠP,QQ,ΡR,ΣS,ΤT,ΘU,ΩV,WW,ΧX,ΥY,ΖZ,αa,βb,ψc,δd,εe,φf,γg,ηh,ιi,ξj,κk,λl,μm,νn,οo,πp,qq,ρr,σs,τt,θu,ωv,ςw,χx,υy,ζz

Example langmap for Dvorak:

'q,\\,w,.e,pr,yt,fy,gu,ci,ro,lp,/[,=],aa,os,ed,uf,ig,dh,hj,tk,nl,s\\;,-',\\;z,qx,jc,kv,xb,bn,mm,w\\,,v.,z/,[-,]=,\"Q,<W,>E,PR,YT,FY,GU,CI,RO,LP,?{,+},AA,OS,ED,UF,IG,DH,HJ,TK,NL,S:,_\",:Z,QX,JC,KV,XB,BN,MM,W<,V>,Z?

You may find the exact format under :help langmap in Vim.

It seems to me like it could be possible to override defaultKeymap in the source code using such a langmap:
Given a parsed langmap, one would simply need to copy every binding once for each of the four contexts and then adjust the left side to the specified map.

My pull request under VsCodeVim includes a langmap parser, so that should not be an issue. The only remaining part would be the logic.

Would this be something you could look into? Otherwise, I could try and understand CM6 Vim's code a little better and make a pull request myself, provided it's something you would be interested in merging in first place.

[nightwing]

Sounds like a useful feature, but maybe instead of overriding the defaultKeymap, we should keep separate langMap variable and convert key in the begining of findKey https://github.com/replit/codemirror-vim/blob/master/src/vim.js#L871

Btw, you could simplify your parsing code a bit using split instead of matchAll

list.split(/((?:[^\\,]|\\.)+),/).map(function (part) {
    if (!part) return;
    var semicolon = part.split(/((?:[^\\;]|\\.)+);/) 
    if (semicolon.length == 3) {
        from = getEscaped(semicolon[1])
        to = getEscaped(semicolon[2])
        ...
    } else if (semicolon.length == 1) {
        pairs = getEscaped(part);
        ...
    }
})

function  getEscaped(str) {
   return str.split(/\\?(.)/).filter(Boolean)
}

I am only unsure about the way that unmapKey is used, as far as i can tell, if user enables langMap for Greek, then changes keyboard layout of the system to qwerty, rc would still replace the character with ψ and not c. Is that the way vim itself works, or am i misunderstanding your code?

[Opisek]

Thanks for the tip with split. If I recall correctly though, I had some issues using that when writing this code, but I'm not sure what they were. I could revisit and test it again.

unmapKey is a slight hack I had to implement to not change VsCodeVim's codebase too much. The underlying idea is however true to Vim. When you press the keys that correspond to ra, only the first one will be remapped. This is so that you can still search for the next occurence of a character, or replace a character in your goal layout, e.g. rα or fα. Optimally, that second keystroke should never be remapped in first place, forcing you to then immediately unmap it, but the exact inner workings will depend on the existing code.

Also, I agree with your proposed remapping at the beginning of findKey being a better solution. I will read a bit more into the source code to understand how keys are handled from the stroke to the executed action.

[nightwing]

@Opisek are you working on this or should i try to implement this? UnmapKey probably should be handled by introducing a new flag for expecting character input which would solve #125 as well.

[Opisek]

@nightwing I'm not currently working on it due to how busy I am these days, but it's definitely in the back of my head waiting until I have some time for it.

Let me see if I've got some time the coming week, cause I would definitely like to give it a shot.

I'm not sure if I understand the connection to the other issue you linked, though. Could you fill me in on your thoughts there?

[Opisek]

I found some time to look into the code and I'm close to finishing up the feature. Right now, I'd just need your opinion on unmapKey logic. You mentioned we could introduce a flag for expecting character input. I don't think that is applicable here though.

Consider a user creating the following two mappings:

• a<any>b
• abd

I will use greek alphabet for this example to minimize confusion.

Now, if a user presses α, it will be interpreted as a, so we'd need to set the flag for expecting a literal character next. If the user now presses β, it will not be remapped, because we were told to expect a literal character. However, if we type δ next, the full captured string will be aβd. Meanwhile, it should've been recognized as abd.

That's why I really think the only option is to unmap literal keys after we're certain we have captured the full binding.

Additionally, I'm not sure #125 could be fixed via such a flag either, because it feels to me like we're unrightfully capturing and interpreting a dead key. Now the question would be, how would one figure out which keys are dead, since that depends on the user's layout. I'll see what I can do about that issue once I'm finished with langmap though.

[nightwing]

How does one define arbitrary a<any>b mapping in vim? As far as i understand untranslated β should be allowed only forf<letter> t<letter> and r<letter>, is that wrong?

[Opisek]

I believe you're right, sorry for the confusion. It does seem like <letter> is only ever the last part of a binding and is not user-remappable. In that case I'll see about implementing the suggested flag. There are in fact more bindings than just the 3 you mentioned, so it's best if I dynamically determine if the next character should be interpreted literally, based on the array of bindings. Thanks for your input.