Thank you for those fast forwarding questions. On the road to victory, my current checkpoint answer would be:
ad 1.
- I think you identify a two-fold problem here: How to fence against changing key layouts (us, fr, …) and how to fence against changing physical layouts (emulated, off the shelf querty, etc)
- I hope it would be possible to access some static handle on the physical keys that is unique per keyboard (maybe such as the ones returned by
showkey --ascii)? - Then, we would “train” kakoune on a physical keyboard layout to correspond positions to let’s say ascii codes or keycodes or similar.
ad 2.
- Surely,
r-thumb&l-thumbwould have to be part of the spec.
The XY coordinates plane does limit the way that non-columnar key layouts could be specified. The more extreme example in the link you provided with the circular layout is for gamers. Maybe it can be safe to postulate: non-columnar-resembling layouts shall not be a first class citizen in the domain of a text editor. Something that a human brain can transform-project onto a grid would be enough which covers almost all keyboard formats, even the most ergonomic ones.
Ideally, a small helper script would guide the user through the mapping process:
Place your hands on what is the home row for you
Type l-pinky[ 0, 0]:
Type l-pinky[-1, 0]:
Type l-pinky[-2, 0]: # omit with ESC since my (most) keyboard doesn't have it, for example
...
would generate some type of ingestable muscle memory map: (ring and middle would probably spare the x axis)
l-pinky[-1, 2]:12 l-pinky[ 0, 2]:13 l-ring[ 3]:14 ...
l-pinky[-1, 1]:34 l-pinky[ 0, 1]:35 l-ring[ 1]:36 ...
l-pinky[-1, 0]:56 l-pinky[ 0, 0]:57 l-ring[ 0]:58 ...
l-pinky[-1,-1]:81 l-pinky[ 0,-1]:82 l-ring[-1]:83 ...
...
Should kakoune ship with a default layout US QUERTY mapping? Maybe. One reason could be to keep current behaviour out of the box when someone just wants to give kakoune a quick shot.
But emphasis should rather be put on a generator tool than trying to ship too much mapping specs.
Kakoune’s default binding could work entirely with the muscle memory locator syntax internally.
Over time, I suspect such change would trigger a slow paradigm shift in the community away from keysym logic towards muscle memory logic. At that stage, I think it will be natural to optimize the command ergonomics accordingly. When that is the case, I could imagine that it will feel natural to revisit the stance on remapping (to muscle memory positions — what would remapping muscle memory positions actually mean?!?!? — such indirection would feel obsolete) vs genuine mapping (to commands). But that’s something that can happily emerge over time, if it wants to.
What do you think? Is this possible?
If your physical keyboard changes, just re-train kakoune. Should be a quick no brainer to do for the user compared to current very convoluted remapping.
EDIT: In case the shift accessor is handled keyboard side, it shall be l-pinky[-1, 2]:12:23 (is it? or does the keyboard still emit a unique identifier to denote the physical key that has been pressed?)
EDIT2: This suggestion operates under the assumption of CSI u being confgured on the terminal, so that no restrictions apply to what modifiers can be used on any given key. See: https://github.com/alexherbo2/alacritty-extended-keys and Taking back control of hjkl with modifiers keys