Round-tripping key definitions

Round-tripping key definitions

[Lars Ingebrigtsen]

It'd be nice if doing a `describe-keymap' would output the same bindings
that we put in.  I mean, on the same form.  If you define a key as
"C-i", that function will describe the key as "TAB", for instance.  (And
the person making that keymap may have meant C-i with "i" being a
mnemonic for something.)

To do this, we'd have to stash the "intended" syntax somewhere, but:

(define-keymap
  "a" 'foo
  "b" 'bar)
=> (keymap (98 . bar) (97 . foo))

(define-keymap
  :full t
  "a" 'foo
  "b" 'bar)
=> (keymap #^[nil nil keymap #^^[3 0...])

In the latter case, we could stash the data in the case table somewhere.
But the sparse syntax doesn't give us a lot of wriggle room.

We could, of course, change the keymap types (since we're already adding
new functions for all of this binding stuff), but it'd be a lot of work.
Anybody got any ideas?

Hm...  while typing this, it occurs to me that we could add an
"impossible" "binding".  I.e.:

(keymap (98 . bar) (97 . foo) (:bindings <hash table>))

`describe-keymap' could use the :bindings entry to look up the intended
syntax (and not output that element).

Yeah!  I think that should work?  (We'd only add this entry if there's
any "ambiguous" keys in the map, so the impact wouldn't be noticeable, I
think.)

Thank you for coming to my TED talk.

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

Re: Round-tripping key definitions

[Stefan Monnier]

> It'd be nice if doing a `describe-keymap' would output the same bindings
> that we put in.  I mean, on the same form.  If you define a key as
> "C-i", that function will describe the key as "TAB", for instance.  (And
> the person making that keymap may have meant C-i with "i" being a
> mnemonic for something.)

FWIW, I think the TAB/C-i, RET/C-m, ESC/C-[, DEL/C-? confusion should be
fixed by really decoupling the two.

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).

You say "for instance" above, but which confusing cases are there other
than the four TAB/C-i, RET/C-m, ESC/C-[, DEL/C-? special cases?

> `describe-keymap' could use the :bindings entry to look up the intended
> syntax (and not output that element).
>
> Yeah!  I think that should work?  (We'd only add this entry if there's
> any "ambiguous" keys in the map, so the impact wouldn't be noticeable, I
> think.)
>
> Thank you for coming to my TED talk.

Truly inspiring.  A have a question: how would you define "ambiguous"?


        Stefan

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

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

> FWIW, I think the TAB/C-i, RET/C-m, ESC/C-[, DEL/C-? confusion should be
> fixed by really decoupling the two.

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

> 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).
>
> You say "for instance" above, but which confusing cases are there other
> than the four TAB/C-i, RET/C-m, ESC/C-[, DEL/C-? special cases?

Well, it's an instance of those four.  😖

But are those the only ones?  Hm...  I guess?

> Truly inspiring.  A have a question: how would you define "ambiguous"?

I would define it ambiguously. 

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

Re: Round-tripping key definitions

[Stefan Monnier]

Lars Ingebrigtsen [2021-11-13 15:50:16] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> FWIW, I think the TAB/C-i, RET/C-m, ESC/C-[, DEL/C-? confusion should be
>> fixed by really decoupling the two.
> 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?

>> 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.

> 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).

>> Truly inspiring.  A have a question: how would you define "ambiguous"?
> I would define it ambiguously. 

Quantum code?


        Stefan

Re: Round-tripping key definitions

[Phil Sainty]

On 2021-11-14 04:23, Stefan Monnier wrote:
> Lars Ingebrigtsen [2021-11-13 15:50:16] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> FWIW, I think the TAB/C-i, RET/C-m, ESC/C-[, DEL/C-? confusion should
>>> be fixed by really decoupling the two.
>> 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?

That somebody could have been me.  My understanding has always been that
a terminal will send ASCII char 9 when you type either the TAB key or 
C-i
(and similarly for the other special cases).

In GUI environments I'm sure the combination of the Ctrl key and "i"
can be recognised independently; but how could that work in terminals?

Or are you suggesting that an explicit binding for "C-i" would cease
to have *any* effect in a terminal, just like bindings for "<tab>"
won't have any effect, because Emacs would no longer recognise ASCII 9
as being "C-i"?  <tab>, C-i, and TAB would be three different things?


-Phil

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

Re: Round-tripping key definitions

[Stefan Monnier]

>>>> 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?

Not in the short term.  In any case, I'd encourage others to try it out,
since nothing beats experience.


        Stefan

Re: Round-tripping key definitions

[Stefan Monnier]

>> And you believed that somebody?
> That somebody could have been me.  My understanding has always been that
> a terminal will send ASCII char 9 when you type either the TAB key or C-i
> (and similarly for the other special cases).

I'm not proposing to solve that problem magically.

I'm proposing to make the key names `C-i` and `TAB` distinct, such that
hitting `C-h c TAB` in a tty would/could tell the users something
like "TAB (translated from C-i) runs the command ...".

Then again, maybe we'd want to finally get rid of the conflation between
"control modifier + key" and "ASCII control char".  But that's harder
(because it affects ELisp source code, where `?\C-i` is 9 rather than
#x4000069, so either we keep `?\C-i` as 9 and introduce a new syntax
for "character i with a control modifier", or we change the value and
risk breaking some programs (tho maybe we can auto-fix the vast
majority with appropriate heuristics)).

[ BTW, I just noticed that `?\C-é` is 137, which seems like a plain bug.  ]

> In GUI environments I'm sure the combination of the Ctrl key and "i"
> can be recognised independently; but how could that work in terminals?

I'm not suggesting to solve this problem (BTW, it can be solved by
having the terminal send a different byte sequence for TAB and C-i,
which several terminals are already able to do, but that's a separate
issue from what is discussed here).


        Stefan

Re: Round-tripping key definitions

[Andreas Schwab]

On Nov 14 2021, Stefan Monnier wrote:

> [ BTW, I just noticed that `?\C-é` is 137, which seems like a plain bug.  ]

That's because ?é is a SINGLE_BYTE_CHAR_P and (<= #o101 (logand ?é
#o137) #o132) (see read_escape).  I think the SINGLE_BYTE_CHAR_P test
should be replaced by ASCII_CHAR_P (it was added in commit 164d590d5c).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Round-tripping key definitions

[Stefan Monnier]

Andreas Schwab [2021-11-14 16:07:26] wrote:
> On Nov 14 2021, Stefan Monnier wrote:
>> [ BTW, I just noticed that `?\C-é` is 137, which seems like a plain bug.  ]
> That's because ?é is a SINGLE_BYTE_CHAR_P and (<= #o101 (logand ?é
> #o137) #o132) (see read_escape).  I think the SINGLE_BYTE_CHAR_P test
> should be replaced by ASCII_CHAR_P (it was added in commit 164d590d5c).

Oh, so I think it was OK originally but became incorrect when we
switched to Unicode.  Fixed now,


        Stefan

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

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

> I'm proposing to make the key names `C-i` and `TAB` distinct, such that
> hitting `C-h c TAB` in a tty would/could tell the users something
> like "TAB (translated from C-i) runs the command ...".

But...  how?  🤨

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

Re: Round-tripping key definitions

[Stefan Monnier]

Lars Ingebrigtsen [2021-11-14 19:03:52] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I'm proposing to make the key names `C-i` and `TAB` distinct, such that
>> hitting `C-h c TAB` in a tty would/could tell the users something
>> like "TAB (translated from C-i) runs the command ...".
>
> But...  how?  🤨

I was thinking of starting with changing `kbd` (and friends) so that

    (kbd "TAB")    =>  [TAB]
    (kbd "M-TAB")  =>  [M-TAB]
    ...

and then look for ways to unbreak the result, such as adding
a `function-key-map` entry from [?\C-i] to [TAB].


        Stefan

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

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

> I was thinking of starting with changing `kbd` (and friends) so that
>
>     (kbd "TAB")    =>  [TAB]
>     (kbd "M-TAB")  =>  [M-TAB]
>     ...
>
> and then look for ways to unbreak the result, such as adding
> a `function-key-map` entry from [?\C-i] to [TAB].

Hm...  but what if the user wanted to bind "C-i" instead?  When hitting
the `C-i' key, won't that get mapped to [TAB], too?

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

Re: Round-tripping key definitions

[Stefan Monnier]

Lars Ingebrigtsen [2021-11-14 19:51:52] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I was thinking of starting with changing `kbd` (and friends) so that
>>
>>     (kbd "TAB")    =>  [TAB]
>>     (kbd "M-TAB")  =>  [M-TAB]
>>     ...
>>
>> and then look for ways to unbreak the result, such as adding
>> a `function-key-map` entry from [?\C-i] to [TAB].
>
> Hm...  but what if the user wanted to bind "C-i" instead?  When hitting
> the `C-i' key, won't that get mapped to [TAB], too?

No, the `function-key-map` entries are only used if there's no binding
for the key.


        Stefan

Re: Round-tripping key definitions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I am not familiar with the term "round-tripping" and I have to guess
what it means.  I think it has to do with using the same syntactic scheme
to describe key bindings in output as to specify them in input.

I think that is a good idea in general, but what it means is not so
simple.  For instance, using the same syntactic scheme does not imply
there can only be one syntax for any given input.

Compare the situation with Lisp objects.  In general, we try to make
printed sexps read back into something similar.  But it is not always
totally identical.  There are printed representations that can't be
read, and there are multiple input representations for the same sexp.
These exist for good reason; to make things more "regular" would be
absurd.

I think we should not arbitrarily try to eliminate all such quirks in 
key sequences either.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

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

> No, the `function-key-map` entries are only used if there's no binding
> for the key.

So...

(local-set-key [TAB]
	       (lambda ()
		 (interactive)
		 (message "Keys: %S" real-this-command)))

(define-key function-key-map [?\C-i] [TAB])

After allowing binding [TAB], hitting `C-i' does not take me to that
[TAB].

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

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> After allowing binding [TAB], hitting `C-i' does not take me to that
> [TAB].

D'oh.  That's the global key binding.  Let's see...  With:

(local-set-key [TAB]
	       (lambda ()
		 (interactive)
		 (message "TAB: %S" (this-command-keys))))
(local-set-key [?\C-i]
	       (lambda ()
		 (interactive)
		 (message "C-i: %S" (this-command-keys))))

(global-set-key [tab] nil)
(global-set-key (kbd "TAB") nil)

(define-key function-key-map [?\C-i] [TAB])
(define-key function-key-map [tab] '[TAB])

Then indeed everything seems to work?  So I guess this would be a
practical solution?  Unless I've missed some combinations to test.

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

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> D'oh.  That's the global key binding.  Let's see...  With:

The following seems to do the trick (in both GUI and TUI Emacs).

(Not meant as a patch, but to illustrate -- we should instead not bind
the stuff that this unbinds.)

So if we do the same with RET and DEL, we should basically be OK?

diff --git a/lisp/indent.el b/lisp/indent.el
index aa6b8d17c4..e8426ae854 100644
--- a/lisp/indent.el
+++ b/lisp/indent.el
@@ -805,7 +805,11 @@ move-to-tab-stop
                 (forward-char -1))
               (delete-region (point) before)))))))
 
-(define-key global-map "\t" 'indent-for-tab-command)
+(define-key global-map [TAB] 'indent-for-tab-command)
+(define-key global-map [?\C-i] nil)
+(define-key global-map [tab] nil)
+(define-key function-key-map [?\C-i] [TAB])
+(define-key function-key-map [tab] [TAB])
 (define-key esc-map "\C-\\" 'indent-region)
 (define-key ctl-x-map "\t" 'indent-rigidly)
 (define-key esc-map "i" 'tab-to-tab-stop)
diff --git a/src/keymap.c b/src/keymap.c
index 29d2ca7ab7..6034b1e569 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1129,8 +1129,10 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 3, 0,
 	    CHECK_CHARACTER_CDR (c);
 	}
 
+	  /*
       if (SYMBOLP (c))
 	silly_event_symbol_error (c);
+	  */
 
       if (FIXNUMP (c)
 	  && (XFIXNUM (c) & meta_bit)


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

Re: Round-tripping key definitions

[Stefan Monnier]

> -(define-key global-map "\t" 'indent-for-tab-command)
> +(define-key global-map [TAB] 'indent-for-tab-command)
> +(define-key global-map [?\C-i] nil)
> +(define-key global-map [tab] nil)
> +(define-key function-key-map [?\C-i] [TAB])
> +(define-key function-key-map [tab] [TAB])

Sadly, I think this will introduce a fair bit of trouble because code
which currently does

    (define-key map "\t" ...)

expects this binding to apply to both `tab` and tty's TAB key.

We could try and fix it by having `tab` first fallback to `?\t` and only
then to `TAB`, but that currently can't be done with `function-key-map`
because `function-key-map` is not applied to its output.

We could do it via ad-hoc code (like we currently have for the
`drag-mouse-1` fallback to `mouse-1`) or we could introduce a new keymap
like `function-key-map` but that's applied repeatedly until it doesn't
apply any more (or until a binding is found).

Or maybe we could do

    (define-key function-key-map [tab] #'some-new-tab-remap)

and then make sure `some-new-tab-remap` can get enough info to figure
out whether this `tab` should be remapped to `TAB` or to `?\C-i`.

I remember wanting such a repeatedly applied keymap a few times in the
past, and similarly getting enough info for a function to be able to
decide whether to do would be useful in other cases as well.


        Stefan

Re: Round-tripping key definitions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Then again, maybe we'd want to finally get rid of the conflation between
  > "control modifier + key" and "ASCII control char".  But that's harder
  > (because it affects ELisp source code, where `?\C-i` is 9 rather than
  > #x4000069,

I think the crucial requirement is that these are two different
character codes, but programs want to treat them as equivalent and
bind them both with one binding.

               so either we keep `?\C-i` as 9 and introduce a new syntax
  > for "character i with a control modifier", or we change the value and
  > risk breaking some programs (tho maybe we can auto-fix the vast
  > majority with appropriate heuristics)).

That would break a lot of old code.  Such incompatibilities are a big
problem -- worse, I think, than the disadvantages of keeping this
point unchamged.  It's not a big problem, just surprising occasionally.

  > [ BTW, I just noticed that `?\C-é` is 137, which seems like a plain bug.  ]

One can argue that it should give an error message, but barring that,
there is no better value it could give.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

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

> Sadly, I think this will introduce a fair bit of trouble because code
> which currently does
>
>     (define-key map "\t" ...)
>
> expects this binding to apply to both `tab` and tty's TAB key.

Well, we could make `keymap-set' do just that (for these three keys), I
guess?  But I guess that takes us back to square one in the
distinguishing-intention game.

> I remember wanting such a repeatedly applied keymap a few times in the
> past, and similarly getting enough info for a function to be able to
> decide whether to do would be useful in other cases as well.

I'm not sure what that would look like...

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

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Well, we could make `keymap-set' do just that (for these three keys), I
> guess?  But I guess that takes us back to square one in the
> distinguishing-intention game.

I'm wondering whether I should just finish up the
store-the-intended-key-in-the-keymap thing I made -- it's very low
impact, and gets us 93% of the way there.  I.e., it makes `C-h b' and
friends display what `keymap-set' was called with, which was my
priority.

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

Re: Round-tripping key definitions

[Stefan Monnier]

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>   > Then again, maybe we'd want to finally get rid of the conflation between
>   > "control modifier + key" and "ASCII control char".  But that's harder
>   > (because it affects ELisp source code, where `?\C-i` is 9 rather than
>   > #x4000069,
> I think the crucial requirement is that these are two different
> character codes,

Indeed, tho they currently aren't.

> but programs want to treat them as equivalent and
> bind them both with one binding.

As long as they're treated as keys, we can probably fix whichever
problem comes up by adding remappings from one to the other, such as via
`function-key-map`.

>   >            so either we keep `?\C-i` as 9 and introduce a new syntax
>   > for "character i with a control modifier", or we change the value and
>   > risk breaking some programs (tho maybe we can auto-fix the vast
>   > majority with appropriate heuristics)).
>
> That would break a lot of old code.

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.

>   > [ BTW, I just noticed that `?\C-é` is 137, which seems like a plain bug.  ]
> One can argue that it should give an error message, but barring that,
> there is no better value it could give.

Of course there is: #x4000000 + ?é
And that's indeed what it now returns (on `master`).


        Stefan

Re: Round-tripping key definitions

[Po Lu]

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

>>   >            so either we keep `?\C-i` as 9 and introduce a new syntax
>>   > for "character i with a control modifier", or we change the value and
>>   > risk breaking some programs (tho maybe we can auto-fix the vast
>>   > majority with appropriate heuristics)).
>>
>> That would break a lot of old code.
>
> 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.

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

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

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

Re: Round-tripping key definitions

[Po Lu]

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

> 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.

That's a relief, thanks.

> 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.

Yes, I noticed that as well.  Handling the shift modifier was also a
huge PITA when developing the Haiku port.

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

The list I gave was in no way conclusive :)  I only named code that
would experience catastrophic failure if the change was made.

For instance, I'm sure the behavior of `C-q C-d' would change if such a
change was made.

Re: Round-tripping key definitions

[Lars Ingebrigtsen]

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

> Of course there is: #x4000000 + ?é
> And that's indeed what it now returns (on `master`).

Speaking of which -- binding "M-a" results in a submap with ESC:

(define-keymap "M-a" 'foo)
=> (keymap (27 keymap (97 . foo)))

And

(key-parse "M-a") => [134217825]

This leads to er interesting issues when trying to map up what the user
sees with what's really there.  Is this something that also could be
tweaked?

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

Re: Round-tripping key definitions

[Stefan Kangas]

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

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

I can't find the file teco.el in our tree or on GNU ELPA.

It seems to be a package on MELPA:

    https://melpa.org/#/teco

Re: Round-tripping key definitions

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> I can't find the file teco.el in our tree or on GNU ELPA.

I got my copy a long time ago off gnu.emacs.sources.  I hear it's also
on the EmacsWiki.

> It seems to be a package on MELPA:

>     https://melpa.org/#/teco

I didn't ever know of it being on MELPA.

Thanks.

Re: Round-tripping key definitions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> That would break a lot of old code.
  > >
  > > 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.

We can't get an idea of the old code that this would break
by checking today's version of master.  Much of the old code
people use was never included in Emacs.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)