Re: Round-tripping key definitions

[Stefan Monnier]

>> I thought so too, but I've been playing with a quick&dirty patch to
>> see how much breakage it introduces and it seems it's not nearly as
>> bad as I thought.  I'm starting to believe that maybe we could pull it
>> off, tho I haven't had enough experience with it yet to be sure.
> Removing the correspondence between ctrl modifier and the ASCII control
> character would at the very least break the xwidget code in a
> non-trivial manner, a and probably a lot of comint-related code too,
> just to name a few.

What gets broken depends on exactly what is done and how (e.g. the
conflation of the control modifier bit with the ASCII control chars is
done "separately" in a few different places (e.g. when processing key
events, OT1H, and when reading ELisp code, OAOH) and it's not
necessarily indispensable to change them all at the same time or in the
same way).

I don't have any plan to push such a change (at least not yet ;-).
I just played with it, to get a feel for what's the landscape like, and
I was surprised to see that it might be not nearly as a bad as I expected.

BTW, in that same vicinity is another (yet more tricky) conflation,
which is the one for the shift modifier.  I have a pretty good idea of
what the control modifier should do ideally (if we could rewrite the
past), but I don't even have a clear idea of how to handle the shift
modifier in a clean and regular way.

> It would also break `teco.el', a fun toy implementing the TECO text
> editor inside GNU Emacs.

If it only breaks `teco.el` and xwidget, then we're in business
(because I'd be happy to update those).

> I have no interest in updating the xwidget code if this change is made.

I'd expect a change to those things would come with the corresponding
changes to the xwidget code, if needed.


        Stefan