Re: Round-tripping key definitions

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I thought I remembered somebody saying that that wasn't really feasible
>> (at least not on terminals)?  If it is, that'd be fantastic.
>
> And you believed that somebody?

I'm very gullible.

>>> Maybe one way to do that is to have a `function-key-map` fallback from
>>> `[?\C-i]`
>>> to `[TAB]` (so `?\C-i` and `tab` would be "equal partners" both of
>>> which default to falling back to the new `TAB` key).
>
> BTW, I haven't thought very hard about the impact in terms of
> compatibility with existing code.

Could you?

>> But are those the only ones?  Hm...  I guess?
>
> That's the question: for those four, the solution you propose is an
> incomplete solution to their problem, so if there aren't any others I'm
> not very favorable to the idea (at least not before we investigate more
> direct solutions (like the one I outlined) and conclude that we have to
> live with the current problem).

It's true that (key-description (kbd "C-m")) => "RET" is unsatisfactory,
but the hacky solution would basically fix this whenever we know which
keymap the "C-m" appears in (like in `C-h b' and the like).  So, yes,
it's incomplete, but it won't be very noticeable.

After poking around some more, I think those four keys are the indeed
the only ones that are problematic here.  SPC is OK, NUL and LFD aren't
used.

By the way, I found this:

(key-description (kbd "C-i")) => "TAB"
(key-description (kbd "C-M-i")) => "C-M-i"

That's probably a bug?  The last one should probably be "M-TAB"?

(equal (kbd "C-M-i") (kbd "M-TAB")) => t

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no