Ctrl-[ ?

Ctrl-[ ?

[Jean-Christophe Helary]

I'm finding that Ctrl-[ is associated to Esc but I have nothing like this in my init file.

Hitting Ctrl-[ in C-h k also gives Esc.

Why is that ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

I found on Stackoverflow that C-[ was pretty much hard-coded as ESC. Why is that ?

https://superuser.com/questions/173851/linux-remap-ctrl-key

Also, there is no mention about that at all in the manual.	

> On Jun 6, 2019, at 13:49, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> 
> I'm finding that Ctrl-[ is associated to Esc but I have nothing like this in my init file.
> 
> Hitting Ctrl-[ in C-h k also gives Esc.
> 
> Why is that ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 2371 bytes --]

Re: Ctrl-[ ?

[Andreas Schwab]

On Jun 06 2019, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:

> I found on Stackoverflow that C-[ was pretty much hard-coded as ESC. Why is that ?

Because ?\[ follows ?Z in ASCII, and ESC follows SUB.

(logand ?\[ #x3f) => 27

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Ctrl-[ ?

[Eli Zaretskii]

On June 6, 2019 10:26:28 AM GMT+03:00, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> I found on Stackoverflow that C-[ was pretty much hard-coded as ESC.
> Why is that ?
> 
> https://superuser.com/questions/173851/linux-remap-ctrl-key
> 
> Also, there is no mention about that at all in the manual.	


It isn't hardcoded in Emacs, it' "hardcoded" in the way the OS produces character codes when you type keys on the keyboard.  C-[ produces ESC for the same reason C-i produces TAB and C-j produces RET: these keys emit the same codes as the corresponding Ctrl sequences.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]



> On Jun 6, 2019, at 19:12, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> On June 6, 2019 10:26:28 AM GMT+03:00, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
>> I found on Stackoverflow that C-[ was pretty much hard-coded as ESC.
>> Why is that ?
>> 
>> https://superuser.com/questions/173851/linux-remap-ctrl-key
>> 
>> Also, there is no mention about that at all in the manual.	
> 
> It isn't hardcoded in Emacs, it' "hardcoded" in the way the OS produces character codes when you type keys on the keyboard.  C-[ produces ESC for the same reason C-i produces TAB and C-j produces RET: these keys emit the same codes as the corresponding Ctrl sequences.

Yes but, in my other applications I do have the ability to use Ctrl+[ in a way that is not ESC. Like assign C-[ as a shortcut similarly to C-].

Is there a way to do the same in emacs ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 2893 bytes --]

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Thu, 6 Jun 2019 21:37:38 +0900
> 
> Yes but, in my other applications I do have the ability to use Ctrl+[ in a way that is not ESC. Like assign C-[ as
> a shortcut similarly to C-].

Do those other applications also support text-mode terminals?

Re: Ctrl-[ ?

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]



> On Jun 6, 2019, at 22:02, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Thu, 6 Jun 2019 21:37:38 +0900
>> 
>> Yes but, in my other applications I do have the ability to use Ctrl+[ in a way that is not ESC. Like assign C-[ as
>> a shortcut similarly to C-].
> 
> Do those other applications also support text-mode terminals?

No, and that's the point.

If I prefer to run Emacs in GUI mode it is because I don't want to be limited by a TTY emulation.
(for ex, the ability to display images/pdfs, etc.)


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 2451 bytes --]

Re: Ctrl-[ ?

[Mattias Engdegård]

6 juni 2019 kl. 12.12 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> It isn't hardcoded in Emacs, it' "hardcoded" in the way the OS produces character codes when you type keys on the keyboard.  C-[ produces ESC for the same reason C-i produces TAB and C-j produces RET: these keys emit the same codes as the corresponding Ctrl sequences.

The above is true when Emacs is running in a terminal. Otherwise, Emacs has code to emulate that behaviour (make_ctrl_char), so that we can enjoy a whiff of early 1960s bit-paired keyboards. And this does appear to be hard-coded, in the sense that it cannot be disabled.

It's somewhat useful for certain expensive keyboards with dodgy escape keys.

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Thu, 6 Jun 2019 14:44:31 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>,
>         Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> 
> 6 juni 2019 kl. 12.12 skrev Eli Zaretskii <eliz@gnu.org>:
> > 
> > It isn't hardcoded in Emacs, it' "hardcoded" in the way the OS produces character codes when you type keys on the keyboard.  C-[ produces ESC for the same reason C-i produces TAB and C-j produces RET: these keys emit the same codes as the corresponding Ctrl sequences.
> 
> The above is true when Emacs is running in a terminal. Otherwise, Emacs has code to emulate that behaviour (make_ctrl_char), so that we can enjoy a whiff of early 1960s bit-paired keyboards. And this does appear to be hard-coded, in the sense that it cannot be disabled.

Why is it useful to have different behavior on GUI and TTY frames?

Re: Ctrl-[ ?

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]



> On Jun 6, 2019, at 22:01, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Mattias Engdegård <mattiase@acm.org>
>> Date: Thu, 6 Jun 2019 14:44:31 +0200
>> Cc: Emacs developers <emacs-devel@gnu.org>,
>>        Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> 
>> 6 juni 2019 kl. 12.12 skrev Eli Zaretskii <eliz@gnu.org>:
>>> 
>>> It isn't hardcoded in Emacs, it' "hardcoded" in the way the OS produces character codes when you type keys on the keyboard.  C-[ produces ESC for the same reason C-i produces TAB and C-j produces RET: these keys emit the same codes as the corresponding Ctrl sequences.
>> 
>> The above is true when Emacs is running in a terminal. Otherwise, Emacs has code to emulate that behaviour (make_ctrl_char), so that we can enjoy a whiff of early 1960s bit-paired keyboards. And this does appear to be hard-coded, in the sense that it cannot be disabled.
> 
> Why is it useful to have different behavior on GUI and TTY frames?

Because expectations are different ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 3141 bytes --]

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Thu, 6 Jun 2019 22:25:17 +0900
> 
>  Why is it useful to have different behavior on GUI and TTY frames?
> 
> Because expectations are different ?

Are they?  I don't think so.

Re: Ctrl-[ ?

[Marcin Borkowski]

On 2019-06-06, at 16:35, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Thu, 6 Jun 2019 22:25:17 +0900
>>
>>  Why is it useful to have different behavior on GUI and TTY frames?
>>
>> Because expectations are different ?
>
> Are they?  I don't think so.

Of course they are.

I don't expect to be able to view a pdf in Emacs on a TTY frame, for
instance.

But (to be more serious) I also expect some keybindings not to work on
a TTY frame.

And let me mention that I consider Jean-Christophe's emails extremely
valuable.  It's not often that we have a normal person (aka
non-(technical geek) - as opposed to a (non-technical) geek, which
Jean-Christophe seems to be;-)) here.  There are people outside IT that
want to use Emacs, and every bit in the manual that is confusing for
them is worth being fixed.

Also, even though I've been an Emacs user for about two decades now, and
I've been a computer geek for about three decades now, the ESC / C-[
legacy is still rather baffling for me.

My 2 cents,

--
Marcin Borkowski
http://mbork.pl

Re: Ctrl-[ ?

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Thu, 6 Jun 2019 22:25:17 +0900
>> 
>>  Why is it useful to have different behavior on GUI and TTY frames?
>> 
>> Because expectations are different ?
>
> Are they?  I don't think so.

Here is my datapoint.

I use emacs in both tty and gui frame.
Mostly I use tty because my emacs runs on a remote server and using mosh
to connect to it is very convenient. But I also use x2go to connect to
the same emacs instance with a gui, using the emacs mtty feature which
is fantastic.

Some keybindings work in gui mode but not in tty mode, like C-RET for
instance. Since theres a shortage of convenient keybindings that work in
both tty and gui this is a bit of a hassle.

Now, some terminal emulators allow configuration of extended escape
sequences being used. So for these emulators one could in principle have
the same behaviour in both gui and tty mode. Sadly my experience is that
this is too flaky to be used, since I've so far found no terminal
emulator that implements all the features I'd like, together with Mosh.



>
-- 
Joakim Verona
joakim@verona.se

Re: Ctrl-[ ?

[Clément Pit-Claudel]

On 2019-06-06 09:01, Eli Zaretskii wrote:
>> From: Mattias Engdegård <mattiase@acm.org>
>> Date: Thu, 6 Jun 2019 14:44:31 +0200
>> Cc: Emacs developers <emacs-devel@gnu.org>,
>>         Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>>
>> 6 juni 2019 kl. 12.12 skrev Eli Zaretskii <eliz@gnu.org>:
>>>
>>> It isn't hardcoded in Emacs, it' "hardcoded" in the way the OS produces character codes when you type keys on the keyboard.  C-[ produces ESC for the same reason C-i produces TAB and C-j produces RET: these keys emit the same codes as the corresponding Ctrl sequences.
>>
>> The above is true when Emacs is running in a terminal. Otherwise, Emacs has code to emulate that behaviour (make_ctrl_char), so that we can enjoy a whiff of early 1960s bit-paired keyboards. And this does appear to be hard-coded, in the sense that it cannot be disabled.
> 
> Why is it useful to have different behavior on GUI and TTY frames?

It's not so much that it's useful to have different behavior; rather, there are limitations that only TTY frames suffer from, and if you mostly or always use GUI frames, it's nice not to suffer from these limitations.

For example in my day to day work I use variable-pitch faces, different font sizes, highlighting in ore colors than my terminal can display, svg support, and, most relevant to the discussion above, keybindings that gnome-terminal doesn't support, such as C-S-> and C-S-< (the location of these keys was convenient, and I knew I wouldn't need the corresponding functions often in TTY frames).

So I guess keeping a consistent experience in TTY and GUI frames isn't as important for me as improving the experience in GUI frames.

(I'm not claiming that Enacs' defaults should diverge between TTY and GUI; just that there are use cases for different behavior on GUI and TTY frames)

Re: Ctrl-[ ?

[Juanma Barranquero]

On Thu, Jun 6, 2019 at 3:28 PM Clément Pit-Claudel
<cpitclaudel@gmail.com> wrote:

> So I guess keeping a consistent experience in TTY and GUI frames isn't as important for me as improving the experience in GUI frames.

Same here. I don't think I've used Emacs on TTY frames... well,
*ever*, except for testing framesets, or researching some bug.

> (I'm not claiming that Enacs' defaults should diverge between TTY and GUI; just that there are use cases for different behavior on GUI and TTY frames)

Agreed.

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 6 Jun 2019 09:26:54 -0400
> 
> > Why is it useful to have different behavior on GUI and TTY frames?
> 
> It's not so much that it's useful to have different behavior; rather, there are limitations that only TTY frames suffer from, and if you mostly or always use GUI frames, it's nice not to suffer from these limitations.

That's not the same.  C-[ being the same as ESC is very basic, like
C-g, so having to remember that it might not work on GUI frames would
be a PITA at least for me.

> So I guess keeping a consistent experience in TTY and GUI frames isn't as important for me as improving the experience in GUI frames.

IMO, being able to bind C-[ to something else is not an important
feature, not enough to break the compatibility.  But that's me.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]



> On Jun 6, 2019, at 23:37, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 6 Jun 2019 09:26:54 -0400
>> 
>>> Why is it useful to have different behavior on GUI and TTY frames?
>> 
>> It's not so much that it's useful to have different behavior; rather, there are limitations that only TTY frames suffer from, and if you mostly or always use GUI frames, it's nice not to suffer from these limitations.
> 
> That's not the same.  C-[ being the same as ESC is very basic,

Well, for some people, obviously not for everybody.

My issue was understanding *why* it was the case. The history with ascii is cute but really makes just as much sense to me as if I had to enter unicode escaped sequences in emacs to be able to type Japanese.

> like C-g, so having to remember that it might not work on GUI frames would be a PITA at least for me.

? Which is not what I'd like to have here.

What I'd like to have is some documentation about that issue in the Emacs manual *and* a documented way to override that behavior on my side.

>> So I guess keeping a consistent experience in TTY and GUI frames isn't as important for me as improving the experience in GUI frames.
> 
> IMO, being able to bind C-[ to something else is not an important
> feature, not enough to break the compatibility.

What compatibility would that break ? If I were to bind C-[ in GUI emacs to something that I find more convenient than ESC in that position, how would that break something ?

>  But that's me.

That could be me too if you explained the issue in a more intelligible way.

Now I see that some things are explained in "Named ASCII Control Characters" in the manual. That part definitely needs some explicit wording for non nerds.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 4243 bytes --]

Re: Ctrl-[ ?

[Clément Pit-Claudel]

On 2019-06-06 10:37, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 6 Jun 2019 09:26:54 -0400
>>
>>> Why is it useful to have different behavior on GUI and TTY frames?
>>
>> It's not so much that it's useful to have different behavior; rather, there are limitations that only TTY frames suffer from, and if you mostly or always use GUI frames, it's nice not to suffer from these limitations.
> 
> That's not the same.  C-[ being the same as ESC is very basic, like
> C-g, so having to remember that it might not work on GUI frames would
> be a PITA at least for me.
> 
>> So I guess keeping a consistent experience in TTY and GUI frames isn't as important for me as improving the experience in GUI frames.
> 
> IMO, being able to bind C-[ to something else is not an important
> feature, not enough to break the compatibility.  But that's me.

I don't have a strong opinion :)  I very seldom have to use an Emacs with someone else's config, so I wouldn't be bothered if the option existed to rebind C-[ to something different from ESC.

By the way, is there a way to change what ESC does? If so, GUI users could just bind <escape> to esc-map and ESC to something else.

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 6 Jun 2019 11:33:56 -0400
> Cc: emacs-devel@gnu.org
> 
> By the way, is there a way to change what ESC does?

It's a prefix command, so I'm not sure what you are asking, exactly.

Re: Ctrl-[ ?

[Clément Pit-Claudel]

On 2019-06-06 13:28, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 6 Jun 2019 11:33:56 -0400
>> Cc: emacs-devel@gnu.org
>>
>> By the way, is there a way to change what ESC does?
> 
> It's a prefix command, so I'm not sure what you are asking, exactly.

I wan wondering whether there was a way to make it a regular (non-prefix) command.  For example, can you bind it to `forward-char'?

Re: Ctrl-[ ?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 6 Jun 2019 13:33:47 -0400
> 
> On 2019-06-06 13:28, Eli Zaretskii wrote:
> >> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> >> Date: Thu, 6 Jun 2019 11:33:56 -0400
> >> Cc: emacs-devel@gnu.org
> >>
> >> By the way, is there a way to change what ESC does?
> > 
> > It's a prefix command, so I'm not sure what you are asking, exactly.
> 
> I wan wondering whether there was a way to make it a regular (non-prefix) command.  For example, can you bind it to `forward-char'?

Can you do that with any other prefix command?

Re: Ctrl-[ ?

[Eli Zaretskii]

> Date: Thu, 06 Jun 2019 20:48:49 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > > It's a prefix command, so I'm not sure what you are asking, exactly.
> > 
> > I wan wondering whether there was a way to make it a regular (non-prefix) command.  For example, can you bind it to `forward-char'?
> 
> Can you do that with any other prefix command?

I'm sorry if that sounded unfriendly.  It's just that the answer is so
obviously YES that I keep thinking I'm missing something in your
questions.  It's like asking whether C-f can be bound to some
command.  Can you tell why you thought there's something special about
ESC?

Re: Ctrl-[ ?

[Clément Pit-Claudel]

On 2019-06-06 14:34, Eli Zaretskii wrote:
>> Date: Thu, 06 Jun 2019 20:48:49 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>>>> It's a prefix command, so I'm not sure what you are asking, exactly.
>>>
>>> I wan wondering whether there was a way to make it a regular (non-prefix) command.  For example, can you bind it to `forward-char'?
>>
>> Can you do that with any other prefix command?
> 
> I'm sorry if that sounded unfriendly.  It's just that the answer is so
> obviously YES that I keep thinking I'm missing something in your
> questions.  It's like asking whether C-f can be bound to some
> command.
I thought so too, but I didn't manage to make it work.  I likely did something silly.  I tried this:

  (global-set-key (kbd "ESC") #'forward-char)

…and all that achieved was to break all keybindings starting with meta.

The reason I'm asking is that, assuming it's possible to rebind ESC, I think there's an easy solution to the OP's question:

Bind <escape> to esc-map
Bind ESC to whatever you want C-[ to do.

As I understood it, the request was this:

On 2019-06-06 08:37, Jean-Christophe Helary wrote:
> […] in my other applications I do have the ability to use Ctrl+[ in a way that is not ESC. Like assign C-[ as a shortcut similarly to C-].
> 
> Is there a way to do the same in emacs ?

Assuming you can bind ESC and <escape> separately, the above should work, shouldn't it?  Maybe I'm missing something obvious.

Clément.

Re: Ctrl-[ ?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 6 Jun 2019 14:48:38 -0400
> 
> > I'm sorry if that sounded unfriendly.  It's just that the answer is so
> > obviously YES that I keep thinking I'm missing something in your
> > questions.  It's like asking whether C-f can be bound to some
> > command.
> I thought so too, but I didn't manage to make it work.  I likely did something silly.  I tried this:
> 
>   (global-set-key (kbd "ESC") #'forward-char)
> 
> …and all that achieved was to break all keybindings starting with meta.

In what buffer?  If there's a local binding, it will shadow the
global one, so to be sure rebind both.

> The reason I'm asking is that, assuming it's possible to rebind ESC, I think there's an easy solution to the OP's question:
> 
> Bind <escape> to esc-map
> Bind ESC to whatever you want C-[ to do.
> 
> As I understood it, the request was this:
> 
> On 2019-06-06 08:37, Jean-Christophe Helary wrote:
> > […] in my other applications I do have the ability to use Ctrl+[ in a way that is not ESC. Like assign C-[ as a shortcut similarly to C-].
> > 
> > Is there a way to do the same in emacs ?
> 
> Assuming you can bind ESC and <escape> separately, the above should work, shouldn't it?

Of course.  Every key can be rebound in Emacs (except C-g, perhaps).

Re: Ctrl-[ ?

[Clément Pit-Claudel]

On 2019-06-06 15:18, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 6 Jun 2019 14:48:38 -0400
>>
>>> I'm sorry if that sounded unfriendly.  It's just that the answer is so
>>> obviously YES that I keep thinking I'm missing something in your
>>> questions.  It's like asking whether C-f can be bound to some
>>> command.
>> I thought so too, but I didn't manage to make it work.  I likely did something silly.  I tried this:
>>
>>   (global-set-key (kbd "ESC") #'forward-char)
>>
>> …and all that achieved was to break all keybindings starting with meta.
> 
> In what buffer?  If there's a local binding, it will shadow the
> global one, so to be sure rebind both.

I *scratch* (so in emacs-lisp-mode).  It does work in fundamental mode, but it still breaks meta (M-x is undefined after redefining ESC)

Re: Ctrl-[ ?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 7 Jun 2019 11:02:12 -0400
> 
> >>   (global-set-key (kbd "ESC") #'forward-char)
> >>
> >> …and all that achieved was to break all keybindings starting with meta.
> > 
> > In what buffer?  If there's a local binding, it will shadow the
> > global one, so to be sure rebind both.
> 
> I *scratch* (so in emacs-lisp-mode).  It does work in fundamental mode, but it still breaks meta (M-x is undefined after redefining ESC)

The original question was about redefining ESC.  How to do that
without making Meta undefined is a separate issue.  (ESC by default is
the prefix key of the Meta keymap, so it's a small wonder that
redefining ESC breaks Meta.  You will have the same effect if you
redefine C-x: all the C-x sequences will stop working.)

Re: Ctrl-[ ?

[Clément Pit-Claudel]

On 2019-06-07 15:44, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 7 Jun 2019 11:02:12 -0400
>>
>>>>   (global-set-key (kbd "ESC") #'forward-char)
>>>>
>>>> …and all that achieved was to break all keybindings starting with meta.
>>>
>>> In what buffer?  If there's a local binding, it will shadow the
>>> global one, so to be sure rebind both.
>>
>> I *scratch* (so in emacs-lisp-mode).  It does work in fundamental mode, but it still breaks meta (M-x is undefined after redefining ESC)
> 
> The original question was about redefining ESC.  How to do that
> without making Meta undefined is a separate issue.  (ESC by default is
> the prefix key of the Meta keymap, so it's a small wonder that
> redefining ESC breaks Meta.  You will have the same effect if you
> redefine C-x: all the C-x sequences will stop working.)

I see, thanks.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 8, 2019, at 4:44, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 7 Jun 2019 11:02:12 -0400
>> 
>>>>  (global-set-key (kbd "ESC") #'forward-char)
>>>> 
>>>> …and all that achieved was to break all keybindings starting with meta.
>>> 
>>> In what buffer?  If there's a local binding, it will shadow the
>>> global one, so to be sure rebind both.
>> 
>> I *scratch* (so in emacs-lisp-mode).  It does work in fundamental mode, but it still breaks meta (M-x is undefined after redefining ESC)
> 
> The original question was about redefining ESC.

Eli, if you refer to my post, then let me assure you that it was not.

The only thing I was talking about was C-[ because I was doing a binding on C-] and I wanted a related one on C-[.

I never wanted to redefine ESC. I was surprised to see that C-[ was equivalent to ESC and that nothing in my preferences or in the manual hinted at a reason for that.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sat, 8 Jun 2019 08:48:17 +0900
> 
> > On Jun 8, 2019, at 4:44, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> Cc: emacs-devel@gnu.org
> >> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> >> Date: Fri, 7 Jun 2019 11:02:12 -0400
> >> 
> >>>>  (global-set-key (kbd "ESC") #'forward-char)
> >>>> 
> >>>> …and all that achieved was to break all keybindings starting with meta.
> >>> 
> >>> In what buffer?  If there's a local binding, it will shadow the
> >>> global one, so to be sure rebind both.
> >> 
> >> I *scratch* (so in emacs-lisp-mode).  It does work in fundamental mode, but it still breaks meta (M-x is undefined after redefining ESC)
> > 
> > The original question was about redefining ESC.
> 
> Eli, if you refer to my post, then let me assure you that it was not.

I quoted the post to which I refer.  It was by Clément, not by you.

> The only thing I was talking about was C-[ because I was doing a binding on C-] and I wanted a related one on C-[.

Yes, I understood that.

Re: Ctrl-[ ?

[Søren Pilgård]

On Fri, Jun 7, 2019 at 9:51 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: emacs-devel@gnu.org
> > From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> > Date: Fri, 7 Jun 2019 11:02:12 -0400
> >
> > >>   (global-set-key (kbd "ESC") #'forward-char)
> > >>
> > >> …and all that achieved was to break all keybindings starting with meta.
> > >
> > > In what buffer?  If there's a local binding, it will shadow the
> > > global one, so to be sure rebind both.
> >
> > I *scratch* (so in emacs-lisp-mode).  It does work in fundamental mode, but it still breaks meta (M-x is undefined after redefining ESC)
>
> The original question was about redefining ESC.  How to do that
> without making Meta undefined is a separate issue.  (ESC by default is
> the prefix key of the Meta keymap, so it's a small wonder that
> redefining ESC breaks Meta.  You will have the same effect if you
> redefine C-x: all the C-x sequences will stop working.)
>

So for a lot of users, using graphical Emacs, not knowing the
intricacies of af tty the following is rather baffling:
C-[ is ESC, ESC is Meta and Meta is Alt.
(For a confusing definition of "is")
This is one of the things that makes Emacs feel very archaic. I do
believe that most users coming to Emacs during the last 5-10 years are
using the graphical version. Yeah we should keep the ability to use
both the tty version and the graphical version as is. But forcing this
schema on everyone is not really beneficial.

Re: Ctrl-[ ?

[Ergus]

On Wed, Jun 12, 2019 at 10:08:44AM +0200, S??ren Pilg??rd wrote:
>On Fri, Jun 7, 2019 at 9:51 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > Cc: emacs-devel@gnu.org
>> > From: Cl??ment Pit-Claudel <cpitclaudel@gmail.com>
>> > Date: Fri, 7 Jun 2019 11:02:12 -0400
>> >
>> > >>   (global-set-key (kbd "ESC") #'forward-char)
>> > >>
>> > >> ???and all that achieved was to break all keybindings starting with meta.
>> > >
>> > > In what buffer?  If there's a local binding, it will shadow the
>> > > global one, so to be sure rebind both.
>> >
>> > I *scratch* (so in emacs-lisp-mode).  It does work in fundamental mode, but it still breaks meta (M-x is undefined after redefining ESC)
>>
>> The original question was about redefining ESC.  How to do that
>> without making Meta undefined is a separate issue.  (ESC by default is
>> the prefix key of the Meta keymap, so it's a small wonder that
>> redefining ESC breaks Meta.  You will have the same effect if you
>> redefine C-x: all the C-x sequences will stop working.)
>>
>
>So for a lot of users, using graphical Emacs, not knowing the
>intricacies of af tty the following is rather baffling:
>C-[ is ESC, ESC is Meta and Meta is Alt.
>(For a confusing definition of "is")
>This is one of the things that makes Emacs feel very archaic. I do
>believe that most users coming to Emacs during the last 5-10 years are
>using the graphical version. Yeah we should keep the ability to use
>both the tty version and the graphical version as is. But forcing this
>schema on everyone is not really beneficial.
>
I partially agree here because the few users I know that came to emacs
are using only the tty version, because we work in servers and remote
machines (and tramp is not always useful for us). Basically we wanted a
decent editor for the terminal without modes.

Said that, with the right terminal emulator (say xterm, rxvt or some
others) it is possible to customize this behavior very similar to what
the gui does. And it is even possible to provide a config to do so (if
there are issues) in order to send different commands for:

C-i /= TAB
C-m /= RET
C-[ /= ESC
C-? /= erase

Or even make it case sensitive:

C-letter /= C-S-letter

So, actually forcing this schema is not due to technical reasons in my
opinion, but backward (human) compatibility.

If sometime this is properly fixed (there is an agreement), then some
terminal users will be allowed to use Control- jkli or hjkl as arrows
and the meta equivalents. But also we will have many new bindings to set
(all the C-S-letter M-S-letter) that potentially could be set to
opposite actions in some cases like undo/redo goto-next/goto-previous,
zap-to-char-forward/zap-to-char-backward or new actions like transpose
lines.

Re: Ctrl-[ ?

[Noam Postavsky]

On Thu, 6 Jun 2019 at 14:34, Eli Zaretskii <eliz@gnu.org> wrote:

> Can you tell why you thought there's something special about
> ESC?

Maybe because there *is* something special about ESC?

(define-key global-map (kbd "ESC") 'forward-char) ;; doesn't work,
breaks all Meta bindings.

<f1> c ESC ESC => ESC ESC (translated from <escape> <escape>) is undefined
<f1> c M-f => M-f is undefined

Re: Ctrl-[ ?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:
> IMO, being able to bind C-[ to something else is not an important
> feature, not enough to break the compatibility.  But that's me.

Perhaps it makes sense from a compatibility standpoint, but I
suspect that many users would be surprised by the inability to
rebind C-[ or C-i.  (Binding C-i also rebinds TAB.)

Would it make sense to show a warning when trying to bind keys such as
C-[ or C-i?  (Or, perhaps better, to show it in the "*Help*" buffer?
C-h k C-[ only shows "ESC- " when I try, though.)

Would it make sense to introduce a variable to turn this behaviour off
in a graphical environment?  The default could stay as is.

Thanks,
Stefan Kangas

Re: Ctrl-[ ?

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]



> On Jun 10, 2019, at 9:23, Stefan Kangas <stefan@marxist.se> wrote:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
>> IMO, being able to bind C-[ to something else is not an important
>> feature, not enough to break the compatibility.  But that's me.
> 
> Perhaps it makes sense from a compatibility standpoint, but I
> suspect that many users would be surprised by the inability to
> rebind C-[ or C-i.  (Binding C-i also rebinds TAB.)

Yes !

> Would it make sense to show a warning when trying to bind keys such as
> C-[ or C-i?  (Or, perhaps better, to show it in the "*Help*" buffer?
> C-h k C-[ only shows "ESC- " when I try, though.)

Yes, that's when I started to be confused...

> Would it make sense to introduce a variable to turn this behaviour off
> in a graphical environment?  The default could stay as is.

Yes :)


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 2980 bytes --]

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 10 Jun 2019 02:23:43 +0200
> 
> Would it make sense to show a warning when trying to bind keys such as
> C-[ or C-i?

Most key bindings are done non-interactively, so how would such
warnings work in practice?

> C-h k C-[ only shows "ESC- " when I try, though.)

That's because the translation is in effect.

> Would it make sense to introduce a variable to turn this behaviour off
> in a graphical environment?

To turn off what behavior?

Re: Ctrl-[ ?

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefan@marxist.se>
>> Date: Mon, 10 Jun 2019 02:23:43 +0200
>> 
>> Would it make sense to show a warning when trying to bind keys such as
>> C-[ or C-i?
>
> Most key bindings are done non-interactively, so how would such
> warnings work in practice?
>
>> C-h k C-[ only shows "ESC- " when I try, though.)
>
> That's because the translation is in effect.
>
>> Would it make sense to introduce a variable to turn this behaviour off
>> in a graphical environment?
>
> To turn off what behavior?

Turn off the translation of C-[ to ESC, C-i to TAB, etc.  Only really
useful in graphical sessions, but I'd support such an option, though I'd
never use it myself.

To play devil's advocate, though, we wouldn't want this to lead to
people producing public modes whose default keybindings depend on this
translation not happening.  Hmm...  I may have just talked myself around
to not wanting the option.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Michael Welsh Duggan <mwd@md5i.com>
> Date: Tue, 11 Jun 2019 11:36:31 -0400
> 
> To play devil's advocate, though, we wouldn't want this to lead to
> people producing public modes whose default keybindings depend on this
> translation not happening.  Hmm...  I may have just talked myself around
> to not wanting the option.

:-)

Re: Ctrl-[ ?

[Yuri Khan]

On Tue, Jun 11, 2019 at 10:49 PM Michael Welsh Duggan <mwd@md5i.com> wrote:

> To play devil's advocate, though, we wouldn't want this to lead to
> people producing public modes whose default keybindings depend on this
> translation not happening.  Hmm...  I may have just talked myself around
> to not wanting the option.

This ship has sailed — we have Org.

Re: Ctrl-[ ?

[Stefan Kangas]

Michael Welsh Duggan <mwd@md5i.com> writes:
>> To turn off what behavior?
>
> Turn off the translation of C-[ to ESC, C-i to TAB, etc.  Only really
> useful in graphical sessions, but I'd support such an option, though I'd
> never use it myself.

Yes, this would be the proposal.

> To play devil's advocate, though, we wouldn't want this to lead to
> people producing public modes whose default keybindings depend on this
> translation not happening.  Hmm...  I may have just talked myself around
> to not wanting the option.

I suggested in a separate email that the byte compiler could warn
when binding C-i or C-[ directly (as opposed to binding TAB or ESC).
In my mind, that should be sufficiently discouraging for package
authors while also allowing users to do this if they wish to do so.
Would that sound more appealing to you?

I'm not familiar with the byte compiler though, so I don't know how
hard this is to do in practice.

Thanks,
Stefan Kangas

Re: Ctrl-[ ?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:
> > Would it make sense to show a warning when trying to bind keys such as
> > C-[ or C-i?
>
> Most key bindings are done non-interactively, so how would such
> warnings work in practice?

My idea was to make the byte compiler warn when binding e.g. C-i or
C-[ directly (as opposed to binding TAB or ESC).

> > C-h k C-[ only shows "ESC- " when I try, though.)
>
> That's because the translation is in effect.

Exactly.  So I suppose showing a warning in the "*Help*" buffer is not
feasible for C-[.

Thanks,
Stefan Kangas

Re: Ctrl-[ ?

[Alan Mackenzie]

Hello, Stefan.

On Mon, Jun 10, 2019 at 02:23:43 +0200, Stefan Kangas wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> > IMO, being able to bind C-[ to something else is not an important
> > feature, not enough to break the compatibility.  But that's me.

> Perhaps it makes sense from a compatibility standpoint, but I
> suspect that many users would be surprised by the inability to
> rebind C-[ or C-i.  (Binding C-i also rebinds TAB.)

> Would it make sense to show a warning when trying to bind keys such as
> C-[ or C-i?  (Or, perhaps better, to show it in the "*Help*" buffer?
> C-h k C-[ only shows "ESC- " when I try, though.)

> Would it make sense to introduce a variable to turn this behaviour off
> in a graphical environment?  The default could stay as is.

Maybe I'm being a bit thick, here, but I cannot for the life of me find
where in the Emacs sources C-[ gets bound for the GUI.

Is C-[ actually bound in Emacs, or is translating it to ESC just the
default of the GUI keyboard, as it is of the tty keyboard?

> Thanks,
> Stefan Kangas

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Ctrl-[ ?

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> Maybe I'm being a bit thick, here, but I cannot for the life of me find
> where in the Emacs sources C-[ gets bound for the GUI.

See make_ctrl_char in src/keyboard.c

Re: Ctrl-[ ?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Why is it useful to have different behavior on GUI and TTY frames?

For those users who don't use Emacs on the terminal (not rare nowadays)
finding that those keys as special is confusing and limiting, as
demonstrated by this thread.

So while it is not useful to have different behavior on GUI and TTY
frames *by default*, it is not useful either to impose the limitations
of TTY frames on GUI frames.

RE: Ctrl-[ ?

[Drew Adams]

> Why is it useful to have different behavior on GUI and TTY frames?

As others have said, it's about _being able_ to
have different behavior.  It's not about changing
the default of having the same behavior on both.

I agree with what everyone else (so far) has said
about this.

It is good to be able to use `C-[' to get `ESC'
behavior, just as it's good to be able to use
`ESC ESC' to get `M-x' behavior.  What's not so
good is to make it hard to get different behavior
for `C-[' and `ESC'.

Re: Ctrl-[ ?

[Stefan Monnier]

> I found on Stackoverflow that C-[ was pretty much hard-coded as
> ESC. Why is that ?

Under most terminals, `escape` and `C-[` send the same byte sequence,
i.e. a single byte 27 which corresponds to the ascii ESC character.

For this reason, when the GUI version of Emacs was introduced (where the
two keys are clearly distinguished), Emacs added `function-key-map`
entries to turn `escape` into ESC when there's no specific `escape`
binding (the mapping from `C-[` to ESC is done at a much lower level,
this one definitely counts as hardcoded).


        Stefan

Re: Ctrl-[ ?

[Ralph Seichter]

* Jean-Christophe Helary:

> I'm finding that Ctrl-[ is associated to Esc but I have nothing like
> this in my init file.

Since the 1970s, Ctrl-[ and Esc produce the same ANSI escape code.

-Ralph

Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

On Thu, Jun 06, 2019 at 01:49:19PM +0900, Jean-Christophe Helary wrote:
> I'm finding that Ctrl-[ is associated to Esc but I have nothing like this in my init file.
> 
> Hitting Ctrl-[ in C-h k also gives Esc.
> 
> Why is that ?

If you have a decent computer (and OS): go open a terminal and type
in "man ascii". You'll see two colums: those less than 64 (i.e.
characters with the second bit set to zero) and those 64 and beyond.

CTRL traditionally makes those "characters" normally non accessible
(because they aren't real characters) accessible by suppressing that
second bit: look to the right column.

Thus, CTRL-@ -> NULL, CTRL-A -> SOH, etc. (notably, CTRL-G is a bell,
CTRL-C is ETX (end of text), CTRL-D EOT (end of transmission). You
might recognize some conventions coming from that.

If you go down that two parallel columns, you'll see that ESC is
paired with CTRL-[

It's in your computer's reptile brain, not always visible, but
lurking :-)

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 6, 2019, at 22:42, tomas@tuxteam.de wrote:
> 
> On Thu, Jun 06, 2019 at 01:49:19PM +0900, Jean-Christophe Helary wrote:
>> I'm finding that Ctrl-[ is associated to Esc but I have nothing like this in my init file.
>> 
>> Hitting Ctrl-[ in C-h k also gives Esc.
>> 
>> Why is that ?
> 
> If you have a decent computer (and OS): go open a terminal and type
> in "man ascii". You'll see two colums: those less than 64 (i.e.
> characters with the second bit set to zero) and those 64 and beyond.
> 
> CTRL traditionally makes those "characters" normally non accessible
> (because they aren't real characters) accessible by suppressing that
> second bit: look to the right column.
> 
> Thus, CTRL-@ -> NULL, CTRL-A -> SOH, etc. (notably, CTRL-G is a bell,
> CTRL-C is ETX (end of text), CTRL-D EOT (end of transmission). You
> might recognize some conventions coming from that.
> 
> If you go down that two parallel columns, you'll see that ESC is
> paired with CTRL-[
> 
> It's in your computer's reptile brain, not always visible, but
> lurking :-)

That explains something (thank you) but not why emacs needs to stick to that.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Stefan Monnier]

> That explains something (thank you) but not why emacs needs to stick to that.

As I explained, it doesn't "stick" to it, in the sense that it is
not hardcoded.

For example you can remove the `escape` => ESC mapping from function-key-map.
And even without that, you can simply add bindings to `escape` and they
will be used when you hit `escape` but not when you hit C-[

See also https://emacs.stackexchange.com/questions/17509 where I show
some other possibility (tho in the context of `tab` vs `C-i` vs TAB, but
which is exactly the same problem).


        Stefan

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 6, 2019, at 23:25, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> See also https://emacs.stackexchange.com/questions/17509 <https://emacs.stackexchange.com/questions/17509> where I show
> some other possibility (tho in the context of `tab` vs `C-i` vs TAB, but
> which is exactly the same problem).

I'm checking "Named ASCII Control Characters", "Rebinding Function Keys" and "Rebinding Keys in Your Init File" and I'm not clear how I can rebind "escape" to a given function.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Noam Postavsky]

On Thu, 6 Jun 2019 at 14:22, Jean-Christophe Helary
<jean.christophe.helary@traduction-libre.org> wrote:

> I'm checking "Named ASCII Control Characters", "Rebinding Function Keys" and "Rebinding Keys in Your Init File" and I'm not clear how I can rebind "escape" to a given function.

Like any other function key:

(define-key global-map (kbd "<escape>") 'a-given-function)

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 7, 2019, at 3:29, Noam Postavsky <npostavs@gmail.com> wrote:
> 
> On Thu, 6 Jun 2019 at 14:22, Jean-Christophe Helary
> <jean.christophe.helary@traduction-libre.org> wrote:
> 
>> I'm checking "Named ASCII Control Characters", "Rebinding Function Keys" and "Rebinding Keys in Your Init File" and I'm not clear how I can rebind "escape" to a given function.
> 
> Like any other function key:
> 
> (define-key global-map (kbd "<escape>") 'a-given-function)

Ok, but if I do that it's my ESC key that is assigned to that function, not C-[

And when I do
(define-key global-map [?\C-[] 'a-given-function)

I get <C-[> is undefined...


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Noam Postavsky]

On Thu, 6 Jun 2019 at 19:12, Jean-Christophe Helary
<jean.christophe.helary@traduction-libre.org> wrote:

>  I'm not clear how I can rebind "escape" to a given function.

> > (define-key global-map (kbd "<escape>") 'a-given-function)
>
> Ok, but if I do that it's my ESC key that is assigned to that function, not C-[

Oh, sorry, I thought that's what you meant by 'rebind "escape"'. I
don't think it's possible to rebind C-[.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 7, 2019, at 8:26, Noam Postavsky <npostavs@gmail.com> wrote:
> 
> On Thu, 6 Jun 2019 at 19:12, Jean-Christophe Helary
> <jean.christophe.helary@traduction-libre.org> wrote:
> 
>> I'm not clear how I can rebind "escape" to a given function.
> 
>>> (define-key global-map (kbd "<escape>") 'a-given-function)
>> 
>> Ok, but if I do that it's my ESC key that is assigned to that function, not C-[
> 
> Oh, sorry, I thought that's what you meant by 'rebind "escape"'. I
> don't think it's possible to rebind C-[.

All this C-[, ESC, escape thing is extremely confusing...

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Thu, 6 Jun 2019 19:26:46 -0400
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> Oh, sorry, I thought that's what you meant by 'rebind "escape"'. I
> don't think it's possible to rebind C-[.

I thought Stefan explained what needs to be done for that, and my
understanding was that it all can be done on the user level.

Re: Ctrl-[ ?

[Noam Postavsky]

On Fri, 7 Jun 2019 at 02:25, Eli Zaretskii <eliz@gnu.org> wrote:

> > I don't think it's possible to rebind C-[.
>
> I thought Stefan explained what needs to be done for that, and my
> understanding was that it all can be done on the user level.

Oh, you're right actually, I hadn't followed the link before. This works:

(define-key input-decode-map "\C-[" [C-left-bracket])
(define-key global-map [C-left-bracket] 'forward-char)

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 7, 2019, at 20:43, Noam Postavsky <npostavs@gmail.com> wrote:
> 
> On Fri, 7 Jun 2019 at 02:25, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>>> I don't think it's possible to rebind C-[.
>> 
>> I thought Stefan explained what needs to be done for that, and my
>> understanding was that it all can be done on the user level.
> 
> Oh, you're right actually, I hadn't followed the link before. This works:
> 
> (define-key input-decode-map "\C-[" [C-left-bracket])

I had missed that part. Thank you so much :)

> (define-key global-map [C-left-bracket] 'forward-char)

Then, this is straightforward :)

Now, what are the other function keys that require a similar treatment ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Stefan Monnier]

> See also https://emacs.stackexchange.com/questions/17509 where I show
> some other possibility (tho in the context of `tab` vs `C-i` vs TAB, but
> which is exactly the same problem).

FWIW, the patch below introduces a much more clear separation between
C-i and TAB and other such things, by distinguishing "control modifier
plus a char" events from the 32 "ASCII control chars".

It introduces various questions about how to print and read
those control thingies in Elisp and in user interactions.

But at least, for a quick 30 seconds test, it seems to handle the
simple cases.


        Stefan


diff --git a/lisp/bindings.el b/lisp/bindings.el
index 36044ab65d..22af38aeef 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -822,7 +822,7 @@ right-char
 see."
   (interactive "^p")
   (if visual-order-cursor-movement
-      (dotimes (i (if (numberp n) (abs n) 1))
+      (dotimes (_ (if (numberp n) (abs n) 1))
 	(move-point-visually (if (and (numberp n) (< n 0)) -1 1)))
     (if (eq (current-bidi-paragraph-direction) 'left-to-right)
 	(forward-char n)
@@ -840,7 +840,7 @@ left-char
 see."
   (interactive "^p")
   (if visual-order-cursor-movement
-      (dotimes (i (if (numberp n) (abs n) 1))
+      (dotimes (_ (if (numberp n) (abs n) 1))
 	(move-point-visually (if (and (numberp n) (< n 0)) 1 -1)))
     (if (eq (current-bidi-paragraph-direction) 'left-to-right)
 	(backward-char n)
@@ -1430,6 +1430,14 @@ ctl-x-4-map
 (define-key special-event-map [sigusr1] 'ignore)
 (define-key special-event-map [sigusr2] 'ignore)
 
+;;;; For merge-ASCII-control-and-CTRL-modifier
+(dotimes (ascii-ctrl 32)
+  (let* ((PLAIN-ctrl (+ 64 ascii-ctrl (ash 1 26))))
+    (dolist (mod (list 0 (ash 1 27))) ;With or without meta
+      (dolist (off (list 0 32))             ;Upper and lowercase
+        (define-key function-key-map (vector (+ PLAIN-ctrl off mod))
+          (vector (+ ascii-ctrl mod)))))))
+
 ;; Don't look for autoload cookies in this file.
 ;; Local Variables:
 ;; no-update-autoloads: t
diff --git a/lisp/simple.el b/lisp/simple.el
index 35022efdf4..184927c928 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8817,7 +8817,7 @@ event-apply-modifier
 LSHIFTBY is the numeric value of this modifier, in keyboard events.
 PREFIX is the string that represents this modifier in an event type symbol."
   (if (numberp event)
-      (cond ((eq symbol 'control)
+      (cond ((and (eq symbol 'control) merge-ASCII-control-and-CTRL-modifier)
 	     (if (<= 64 (upcase event) 95)
 		 (- (upcase event) 64)
 	       (logior (ash 1 lshiftby) event)))
diff --git a/src/keyboard.c b/src/keyboard.c
index 35557e226c..9c92a7ccfd 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2009,7 +2009,7 @@ make_ctrl_char (int c)
   /* Save the upper bits here.  */
   int upper = c & ~0177;
 
-  if (! ASCII_CHAR_P (c))
+  if (! ASCII_CHAR_P (c) || !merge_ascii_control_and_ctrl_modifier)
     return c |= ctrl_modifier;
 
   c &= 0177;
@@ -11811,6 +11811,11 @@ This inhibits recording input events for the purposes of keyboard
 macros, dribble file, and `recent-keys'.
 Internal use only.  */);
 
+  DEFVAR_BOOL ("merge-ASCII-control-and-CTRL-modifier",
+               merge_ascii_control_and_ctrl_modifier,
+               doc: /* When non-nil, C-i is the same as TAB.  */);
+  merge_ascii_control_and_ctrl_modifier = false;
+
   pdumper_do_now_and_after_load (syms_of_keyboard_for_pdumper);
 }
 
diff --git a/src/keymap.c b/src/keymap.c
index 78cd7d2990..16afdefab0 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -2130,8 +2130,9 @@ push_key_description (EMACS_INT ch, char *p)
       c -= alt_modifier;
     }
   if ((c & ctrl_modifier) != 0
-      || (c2 < ' ' && c2 != 27 && c2 != '\t' && c2 != Ctl ('M'))
-      || tab_as_ci)
+      || (merge_ascii_control_and_ctrl_modifier
+          && ((c2 < ' ' && c2 != 27 && c2 != '\t' && c2 != Ctl ('M'))
+              || tab_as_ci)))
     {
       *p++ = 'C';
       *p++ = '-';
@@ -2169,11 +2170,7 @@ push_key_description (EMACS_INT ch, char *p)
 	  *p++ = 'S';
 	  *p++ = 'C';
 	}
-      else if (tab_as_ci)
-	{
-	  *p++ = 'i';
-	}
-      else if (c == '\t')
+      else if (c == '\t' && merge_ascii_control_and_ctrl_modifier)
 	{
 	  *p++ = 'T';
 	  *p++ = 'A';
@@ -2187,7 +2184,11 @@ push_key_description (EMACS_INT ch, char *p)
 	}
       else
 	{
-	  /* `C-' already added above.  */
+          if (!merge_ascii_control_and_ctrl_modifier)
+            {
+	      *p++ = '\\';
+	      *p++ = '^';
+            }
 	  if (c > 0 && c <= Ctl ('Z'))
 	    *p++ = c + 0140;
 	  else

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 07 Jun 2019 18:04:11 -0400
> 
> FWIW, the patch below introduces a much more clear separation between
> C-i and TAB and other such things, by distinguishing "control modifier
> plus a char" events from the 32 "ASCII control chars".
> 
> It introduces various questions about how to print and read
> those control thingies in Elisp and in user interactions.
> 
> But at least, for a quick 30 seconds test, it seems to handle the
> simple cases.

Thanks, but if you intend to install this, please be sure to call it
out in NEWS and maybe also document in the manuals.

Re: Ctrl-[ ?

[Stefan Monnier]

>> But at least, for a quick 30 seconds test, it seems to handle the
>> simple cases.
> Thanks, but if you intend to install this, please be sure to call it
> out in NEWS and maybe also document in the manuals.

Oh, I think it's pretty far from installable.  
It's more like a proof of concept.


        Stefan

Re: Ctrl-[ ?

[Emanuel Berg via help-gnu-emacs]

Jean-Christophe Helary wrote:

> I'm finding that Ctrl-[ is associated to Esc
> but I have nothing like this in my init file.
>
> Hitting Ctrl-[ in C-h k also gives Esc.

You can have that if you use Emacs in a
Linux VT/tty/the console.

I have C-[ tell me, when I hit it right now
typing this, that <C-left-bracket> is
undefined! (That means, it can be defined just
like any other keystroke, only it isn't, at
least not in this mode.)

Here is a tutorial [1] I wrote a long time ago.
Probably, I would put things a little
differently if I'd revise it today. But I don't
feel the need to do so as the technical side of
it should be correct.


[1] https://dataswamp.org/~incal/tty-emacs-keys.txt

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 7, 2019, at 12:36, Emanuel Berg via help-gnu-emacs <help-gnu-emacs@gnu.org> wrote:
> 
> Jean-Christophe Helary wrote:
> 
>> I'm finding that Ctrl-[ is associated to Esc
>> but I have nothing like this in my init file.
>> 
>> Hitting Ctrl-[ in C-h k also gives Esc.
> 
> You can have that if you use Emacs in a
> Linux VT/tty/the console.

What I'd like to have, is the ability to bind C-[ just like I can bind C-], in GUI emacs (since console emacs seems to not allow to do that easily).

And thank you for the link.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Emanuel Berg via help-gnu-emacs]

Jean-Christophe Helary wrote:

> What I'd like to have, is the ability to bind
> C-[ just like I can bind C-], in GUI emacs
> (since console emacs seems to not allow to do
> that easily).

It is easy to do it in console Emacs - just
read the tutorial :)

In GUI Emacs I have no clue how to do it.
Perhaps one must mess with X even.

And FTR obviously I don't encourage anyone to
switch from GUI Emacs to console Emacs just
because of this, if they like GUI Emacs :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 7, 2019, at 13:43, Emanuel Berg via help-gnu-emacs <help-gnu-emacs@gnu.org> wrote:
> 
> Jean-Christophe Helary wrote:
> 
> In GUI Emacs I have no clue how to do it.
> Perhaps one must mess with X even.

macOS here :)

> And FTR obviously I don't encourage anyone to
> switch from GUI Emacs to console Emacs just
> because of this, if they like GUI Emacs :)

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Fri, 7 Jun 2019 13:30:00 +0900
> 
> What I'd like to have, is the ability to bind C-[ just like I can bind C-], in GUI emacs (since console emacs seems to not allow to do that easily).

Stefan explained up-thread (though perhaps on emacs-devel and not
here) what needs to be done for that, so I'm unsure what are your
difficulties in this matter.  Maybe describe what you tried in more
detail?

Re: Ctrl-[ ?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> What I'd like to have, is the ability to bind C-[ just like I can
>> bind C-], in GUI emacs (since console emacs seems to not allow to do
>> that easily).
>
> Stefan explained up-thread (though perhaps on emacs-devel and not
> here) what needs to be done for that, so I'm unsure what are your
> difficulties in this matter.  Maybe describe what you tried in more
> detail?

The OP is explaining himself quite clearly. There is no reason
whatsoever to disallow binding C-[ on GUI Emacs the same way you can
bind any other key.

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 07 Jun 2019 10:04:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> What I'd like to have, is the ability to bind C-[ just like I can
> >> bind C-], in GUI emacs (since console emacs seems to not allow to do
> >> that easily).
> >
> > Stefan explained up-thread (though perhaps on emacs-devel and not
> > here) what needs to be done for that, so I'm unsure what are your
> > difficulties in this matter.  Maybe describe what you tried in more
> > detail?
> 
> The OP is explaining himself quite clearly.

I thought so was I.

> There is no reason whatsoever to disallow binding C-[ on GUI Emacs
> the same way you can bind any other key.

My understanding of what Stefan wrote was that this is NOT disallowed.

There's no reason to chastise me, even if it turns out I've
misunderstood what Stefan said.  That's why I asked Jean-Christophe to
describe what he tried -- to clear up any possible misunderstandings,
including mine.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 7, 2019, at 17:44, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Fri, 07 Jun 2019 10:04:27 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> What I'd like to have, is the ability to bind C-[ just like I can
>>>> bind C-], in GUI emacs (since console emacs seems to not allow to do
>>>> that easily).
>>> 
>>> Stefan explained up-thread (though perhaps on emacs-devel and not
>>> here) what needs to be done for that, so I'm unsure what are your
>>> difficulties in this matter.  Maybe describe what you tried in more
>>> detail?
>> 
>> The OP is explaining himself quite clearly.
> 
> I thought so was I.
> 
>> There is no reason whatsoever to disallow binding C-[ on GUI Emacs
>> the same way you can bind any other key.
> 
> My understanding of what Stefan wrote was that this is NOT disallowed.
> 
> There's no reason to chastise me, even if it turns out I've
> misunderstood what Stefan said.  That's why I asked Jean-Christophe to
> describe what he tried -- to clear up any possible misunderstandings,
> including mine.

As I replied to Noam, I had not understood the 

(define-key input-decode-map "\C-[" [C-left-bracket])

part

so I tried a number of things that messed my setup had to restart, try again, etc. without any success.

I still don't understand where that "left-bracket" comes from so if you could explain that would be extra nice.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Noam Postavsky]

On Fri, 7 Jun 2019 at 09:23, Jean-Christophe Helary
<jean.christophe.helary@traduction-libre.org> wrote:

> (define-key input-decode-map "\C-[" [C-left-bracket])

> I still don't understand where that "left-bracket" comes from so if you could explain that would be extra nice.

It's just an arbitrary symbol choice, you can choose a different one
if you like.

(define-key input-decode-map "\C-[" [C-open-square])
(define-key global-map [C-open-square] 'forward-char)

So if I understand correctly, what happens is that Emacs gets Ctrl+[
from the windowing system, translates that into the ASCII ESC
character (aka 27, aka #x1B, aka ^[, aka \C-[). Then runs it through
input-decode-map which translates it to C-open-square like we told it
to. And then we can use C-open-square in keybindings as normal.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 7, 2019, at 22:54, Noam Postavsky <npostavs@gmail.com> wrote:
> 
> On Fri, 7 Jun 2019 at 09:23, Jean-Christophe Helary
> <jean.christophe.helary@traduction-libre.org> wrote:
> 
>> (define-key input-decode-map "\C-[" [C-left-bracket])
> 
>> I still don't understand where that "left-bracket" comes from so if you could explain that would be extra nice.
> 
> It's just an arbitrary symbol choice, you can choose a different one
> if you like.
> 
> (define-key input-decode-map "\C-[" [C-open-square])
> (define-key global-map [C-open-square] 'forward-char)

Ok, but the key here (no pun intended) is to use input-decode-map before binding the thing, right ?

I just checked the manual and that's a bit arcade to say the least, but at least I know where the info is hidden now...

> So if I understand correctly, what happens is that Emacs gets Ctrl+[
> from the windowing system, translates that into the ASCII ESC
> character (aka 27, aka #x1B, aka ^[, aka \C-[). Then runs it through
> input-decode-map which translates it to C-open-square like we told it
> to. And then we can use C-open-square in keybindings as normal.

Thank you again for your explanations.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Noam Postavsky]

On Fri, 7 Jun 2019 at 11:11, Jean-Christophe Helary
<jean.christophe.helary@traduction-libre.org> wrote:

> > (define-key input-decode-map "\C-[" [C-open-square])
> > (define-key global-map [C-open-square] 'forward-char)
>
> Ok, but the key here (no pun intended) is to use input-decode-map before binding the thing, right ?

You need to evaluate the (define-key input-decode-map ...) to let the
binding work, but the order you do it in doesn't matter.

Re: Ctrl-[ ?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> What I'd like to have, is the ability to bind C-[ just like I can
>> >> bind C-], in GUI emacs (since console emacs seems to not allow to do
>> >> that easily).
>> >
>> > Stefan explained up-thread (though perhaps on emacs-devel and not
>> > here) what needs to be done for that, so I'm unsure what are your
>> > difficulties in this matter.  Maybe describe what you tried in more
>> > detail?
>> 
>> The OP is explaining himself quite clearly.
>
> I thought so was I.
>
>> There is no reason whatsoever to disallow binding C-[ on GUI Emacs
>> the same way you can bind any other key.
>
> My understanding of what Stefan wrote was that this is NOT disallowed.

The key phrase is "the same way you can bind any other key." Stefan's
suggestion does not comply with that.

> There's no reason to chastise me,

I'm no one to chastise anyone. Sometimes I'm a bit too dry.

> even if it turns out I've misunderstood what Stefan said. That's why I
> asked Jean-Christophe to describe what he tried -- to clear up any
> possible misunderstandings, including mine.

One thing that I'll like to know is why the hard restriction about
C-[/C-i exists at all. It is understandable that the default bindings
mimic what you get on the terminal, but forcing the user to jump through
hoops to rebind those keys helps no one. It looks as if a primitive
implementation detail remained like a living fossil to this days on the
C code base.

I suspect that it is related to how several Emacs hackers reacted to the
question posed by the OP: as if he were obviously wrong when requesting
that C-[ to do anything else. It seems that, on this topic, there are
two camps: those tty-minded and those gui-minded.

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 07 Jun 2019 15:45:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> There is no reason whatsoever to disallow binding C-[ on GUI Emacs
> >> the same way you can bind any other key.
> >
> > My understanding of what Stefan wrote was that this is NOT disallowed.
> 
> The key phrase is "the same way you can bind any other key." Stefan's
> suggestion does not comply with that.

For me, the key part was "disallowed".

> > There's no reason to chastise me,
> 
> I'm no one to chastise anyone. Sometimes I'm a bit too dry.

This is one of those times, I guess.

> One thing that I'll like to know is why the hard restriction about
> C-[/C-i exists at all.

That was already explained: the reason is history and the desire to
have identical behavior by default on all frame types.

> It is understandable that the default bindings mimic what you get on
> the terminal, but forcing the user to jump through hoops to rebind
> those keys helps no one.

I don't see how we can avoid jumping through hoops when the text
terminal produces an ASCII key code whereas a GUI terminal doesn't.  I
invite you to read keyboard.c and keymap.c, where you will find a few
more "accidents" like this.

Re: Ctrl-[ ?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> There is no reason whatsoever to disallow binding C-[ on GUI Emacs
>> >> the same way you can bind any other key.
>> >
>> > My understanding of what Stefan wrote was that this is NOT disallowed.
>> 
>> The key phrase is "the same way you can bind any other key." Stefan's
>> suggestion does not comply with that.
>
> For me, the key part was "disallowed".

If *-set-key functions don't work with those combinations, as far as the
user is concerned, he is disallowed to bind them. Not everyone has a
Stefan at hand to come with a hack to work around the limitation.

>> One thing that I'll like to know is why the hard restriction about
>> C-[/C-i exists at all.
>
> That was already explained: the reason is history and the desire to
> have identical behavior by default on all frame types.

It is easy to understand from where it came, what is puzzling is the
fact that it remained to this day.

>> It is understandable that the default bindings mimic what you get on
>> the terminal, but forcing the user to jump through hoops to rebind
>> those keys helps no one.
>
> I don't see how we can avoid jumping through hoops when the text
> terminal produces an ASCII key code whereas a GUI terminal doesn't.  I
> invite you to read keyboard.c and keymap.c, where you will find a few
> more "accidents" like this.

It is not possible (and even more practical than sprinkling the C code
base with special cases) to bind those key combinations to the
terminal-emulation functionality using the normal methods (keymaps) when
running as a gui? Or is it the problem that gui and tty frames can't
have different keymaps?

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 07 Jun 2019 20:20:29 +0200
> 
> If *-set-key functions don't work with those combinations, as far as the
> user is concerned, he is disallowed to bind them.

But those functions do work with these keys, you just need to know
what you are doing, in order not to shoot yourself in the foot.

> Not everyone has a Stefan at hand to come with a hack to work around
> the limitation.

What's wrong with asking Stefan (or any other expert) when you want to
do something unusual?  No one can know everything.  Treating every
tricky solution as meaning you are "disallowed" is quite extreme.

> It is easy to understand from where it came, what is puzzling is the
> fact that it remained to this day.

There's no puzzle from where I stand.

> > I don't see how we can avoid jumping through hoops when the text
> > terminal produces an ASCII key code whereas a GUI terminal doesn't.  I
> > invite you to read keyboard.c and keymap.c, where you will find a few
> > more "accidents" like this.
> 
> It is not possible (and even more practical than sprinkling the C code
> base with special cases) to bind those key combinations to the
> terminal-emulation functionality using the normal methods (keymaps) when
> running as a gui? Or is it the problem that gui and tty frames can't
> have different keymaps?

I don't understand the questions.  All the various variables mentioned
in this thread had names that end in "-map", which means they are
keymaps.  Some keys are processed via several keymaps before their
bound functions are invoked.  So we do definitely use keymaps for this
functionality.

As for keymaps for gui and tty, I believe they are different: see
lisp/term/*.el, where each terminal/emulator has its own keys in the
keymap.

I don't think the issue in this thread was about changing the default
behavior, so whether tty and gui have different keymaps is not the
issue.  The issue is that remapping some keys is trickier than others.

Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

On Fri, Jun 07, 2019 at 03:45:29PM +0200, Óscar Fuentes wrote:

[...]

> One thing that I'll like to know is why the hard restriction about
> C-[/C-i exists at all.

As we've found out, it's not a hard restriction. Just a strong
suggestion.

I think the problem is one of "frame of reference". There's a
(understandable) strong desire to have Emacs behave (as far as
possible) similarly on different display devices. Therefore it
makes sense to unify those things in the GUI that are unified
(by the display device) on a TTY. So you can have the same
keybindings for both.

Imagine for a moment someone binding ESC to some function (or,
since ESC is already taken, let's say DLE, which on a TTY is
equivalent to CTRL-P, hexadecimal 10). Let's assume that user
states the binding in her ~/.emacs/init.el. She would have all
right to expect that things work the same for a TTY and say, X.

Therefore it makes sense to (by default!) unify them under X,
although in that context, you could differentiate them.

To me, architecturally, the right thing to do is to introduce
another mapping layer which does that unification -- before
the regular keymaps get a chance to act. As far as I understood,
this is input-decode-map.

This being Emacs, you are of course allowed to tinker with
that.

Seen from here, that hoop makes sense. It will stop making sense
once the TTY backends are gone (this may take some time: even
the newfangled Raspberry Pi come with a serial interface :-)

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Ctrl-[ ?

[Francis Belliveau]

I think that a lot of you are missing the point that was made early on in the discussion.  This mapping of ASCII cntrol characters is a definition made by convention since the day of the Teletype machines.  It is how the ASCII character set was defined.

Some OS/driver implementations may hide it entirely from the application at the keyboard driver level.  When that it the case there would be no way for emacs to tell the difference between the C-[ and ESC keys because the OS-level keyboard driver sends the same code for both.  Think of these as synonyms.

If you are having trouble, the problem may be at that level or possibly in the "term-caps" definition in use.

Personally, I use C-i, C-[ as often as I use the backspace/delete and meta or escape keys.  It it just a matter of what is easier to use based on where my fingers, or what other keys I need to hit, are at the time.

Good Luck,
Fran


> On Jun 7, 2019, at 12:30, tomas@tuxteam.de wrote:
> 
> On Fri, Jun 07, 2019 at 03:45:29PM +0200, Óscar Fuentes wrote:
> 
> [...]
> 
>> One thing that I'll like to know is why the hard restriction about
>> C-[/C-i exists at all.
> 
> As we've found out, it's not a hard restriction. Just a strong
> suggestion.
> [...]
> Cheers
> -- tomás

Re: Ctrl-[ ?

[Óscar Fuentes]

Francis Belliveau <f.belliveau@comcast.net> writes:

> I think that a lot of you are missing the point that was made early on
> in the discussion. This mapping of ASCII cntrol characters is a
> definition made by convention since the day of the Teletype machines.
> It is how the ASCII character set was defined.

So what? Why a GUI user should be inconvenienced or prevented to bind
C-i, C-[, etc. to whatever he pleases the same way he binds any other
key combination? You can't bind C-[ on a terminal, because there is a
technical limitation, ok. But why you can't bind it either on a GUI,
where the technical limitation does not exist?

Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Sat, Jun 08, 2019 at 02:31:50AM +0200, Óscar Fuentes wrote:
> Francis Belliveau <f.belliveau@comcast.net> writes:
> 
> > I think that a lot of you are missing the point that was made early on
> > in the discussion. This mapping of ASCII cntrol characters is a
> > definition made by convention since the day of the Teletype machines.
> > It is how the ASCII character set was defined.
> 
> So what? Why a GUI user should be inconvenienced or prevented to bind
> C-i, C-[, etc. to whatever he pleases the same way he binds any other
> key combination?

It /is/ possible: thus I don't quite understand your anger here.

I think it's OK for it to be discouraged by default. It's OK for it
to be discouraged for "official" Emacs packages. Because there's some
value in Emacs behaving consistently across backends by default
(as much as possible: it's clear that you can't display a PNG on
a VT220, at least not without some compromise in quality).

Perhaps the ways have to be documented better, and see Stefan's efforts
in making it easier.

Let me repeat here: there is some value in Emacs behaving consistently
across backends (few editors out there, if any, cover the span from
VT220 to X so elegantly). There are folks who use Emacs simultaneously
with different backends.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Ctrl-[ ?

[조성빈 via help-gnu-emacs]

2019. 6. 8. 오후 5:44, tomas@tuxteam.de 작성:

>> On Sat, Jun 08, 2019 at 02:31:50AM +0200, Óscar Fuentes wrote:
>> Francis Belliveau <f.belliveau@comcast.net> writes:
>> 
>>> I think that a lot of you are missing the point that was made early on
>>> in the discussion. This mapping of ASCII cntrol characters is a
>>> definition made by convention since the day of the Teletype machines.
>>> It is how the ASCII character set was defined.
>> 
>> So what? Why a GUI user should be inconvenienced or prevented to bind
>> C-i, C-[, etc. to whatever he pleases the same way he binds any other
>> key combination?
> 
> It /is/ possible: thus I don't quite understand your anger here.
> 
> I think it's OK for it to be discouraged by default. It's OK for it
> to be discouraged for "official" Emacs packages.

Well, I’m not sure ‘discouraging’ is to ‘encourage users to use hacky solutions’ :-(
I would rather like if I can rebind them without an hassle, and Emacs can emit a warning when Emacs is executed insidea terminal.

> Because there's some
> value in Emacs behaving consistently across backends by default
> (as much as possible: it's clear that you can't display a PNG on
> a VT220, at least not without some compromise in quality).

Well, I remember C-/ not working in terminals while working in GUI Emacs... I’m fine with that; but that also means C-[ should be rebindable without hassle.

> Perhaps the ways have to be documented better, and see Stefan's efforts
> in making it easier.
> 
> Let me repeat here: there is some value in Emacs behaving consistently
> across backends (few editors out there, if any, cover the span from
> VT220 to X so elegantly). There are folks who use Emacs simultaneously
> with different backends.

Well, Emacs should focus consistency between major/minor modes first since there are a lot more folks who use Emacs simultaneously with between lots of major modes... (which is being discussed in the ‘Is elisp really slow?’ thread... :-))

> Cheers
> -- tomás

Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

On Sat, Jun 08, 2019 at 08:48:49PM +0900, 조성빈 wrote:

[...]

> Well, I’m not sure ‘discouraging’ is to ‘encourage users to use hacky solutions’ :-(

OK, let's agree to differ, then.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Ctrl-[ ?

[Óscar Fuentes]

<tomas@tuxteam.de> writes:

> On Sat, Jun 08, 2019 at 02:31:50AM +0200, Óscar Fuentes wrote:
>> Francis Belliveau <f.belliveau@comcast.net> writes:
>> 
>> > I think that a lot of you are missing the point that was made early on
>> > in the discussion. This mapping of ASCII cntrol characters is a
>> > definition made by convention since the day of the Teletype machines.
>> > It is how the ASCII character set was defined.
>> 
>> So what? Why a GUI user should be inconvenienced or prevented to bind
>> C-i, C-[, etc. to whatever he pleases the same way he binds any other
>> key combination?
>
> It /is/ possible:

It is *possible*. OTOH (local-set-key "\C-[" 'foo) does not work, which
is an obvious bug on my book. If it is a bug on the implementation or on
the documentation, is another topic. (for me, as an user, it is a bug on
the implementation)

> thus I don't quite understand your anger here.

Please don't add emotion or hidden intent to written expressions on
technical forums, it poisons the discussion.

> I think it's OK for it to be discouraged by default. It's OK for it
> to be discouraged for "official" Emacs packages. Because there's some
> value in Emacs behaving consistently across backends by default
> (as much as possible: it's clear that you can't display a PNG on
> a VT220, at least not without some compromise in quality).
>
> Perhaps the ways have to be documented better, and see Stefan's efforts
> in making it easier.
>
> Let me repeat here: there is some value in Emacs behaving consistently
> across backends (few editors out there, if any, cover the span from
> VT220 to X so elegantly). There are folks who use Emacs simultaneously
> with different backends.

Sorry, but this makes no sense. Nobody is asking for a change on the
default bindings, what we are saying it that the user should be allowed
to set the binding the same way he does for any other binding. It is not
reasonable to expect from the user knowledge about ancient technologies
and the limitations they imposed on the Emacs implementation that deals
with them.

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 08 Jun 2019 15:06:54 +0200
> 
> Nobody is asking for a change on the default bindings, what we are
> saying it that the user should be allowed to set the binding the
> same way he does for any other binding.

If you or someone else believe they know enough about the Emacs
keyboard input processing to propose its redesign which will satisfy
the above requirement, while OTOH avoiding any breakage of the current
defaults which map certain function keys to ASCII characters, or to
the related features (such as input method processing), then by all
means go ahead (just not here, on emacs-devel, please).

Current situation is nowhere near such expertise.  Suffices it to say
that several times during the recent years when we needed to make
seemingly-simple changes and fixes in that code, no one had the
courage to approve such changes.  For some of them, it later turned
out that we broke some subtle but important use cases, for others we
still have our fingers crossed.  So please don't expect any
significant redesigns in that any time soon, as long as all we do is
vent steam here.  We have an enormously complex piece of software on
our hands, and we have no better choice than going the "inconvenient"
ways when we want to rebind an unusual key.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 8, 2019, at 22:30, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> We have an enormously complex piece of software on
> our hands, and we have no better choice than going the "inconvenient"
> ways when we want to rebind an unusual key.

In all honesty:

(define-key input-decode-map "\C-[" [C-left-bracket])
(define-key global-map [C-left-bracket] 'myfunction)

is not inconvenient at all. What is inconvenient is the discovery process.

Knowing what I know about emacs (which is above the casual user) and even with the willingness to go through the manual, it would have been (it *has* been) impossible for me to find that solution.

Now, what I'd love to know is what are the other "unusual" keys, because as a group, they deserve a few more lines in the manual.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Sat, Jun 08, 2019 at 10:54:17PM +0900, Jean-Christophe Helary wrote:
> 
> 
> > On Jun 8, 2019, at 22:30, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > We have an enormously complex piece of software on
> > our hands, and we have no better choice than going the "inconvenient"
> > ways when we want to rebind an unusual key.
> 
> In all honesty:
> 
> (define-key input-decode-map "\C-[" [C-left-bracket])
> (define-key global-map [C-left-bracket] 'myfunction)
> 
> is not inconvenient at all. What is inconvenient is the discovery process.

Then documentation is the way forward, perhaps?

> Knowing what I know about emacs (which is above the casual user) and even with the willingness to go through the manual, it would have been (it *has* been) impossible for me to find that solution.
> 
> Now, what I'd love to know is what are the other "unusual" keys, because as a group, they deserve a few more lines in the manual.

A good set of candidates would be all those control characters
(the first 31 in man ascii(7)) which are customarily bound
to a key (like CTRL-C, aka ETX, CTRL-\, aka FS, and so on).

Care to compile a list?

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 8, 2019, at 23:03, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
> 
> On Sat, Jun 08, 2019 at 10:54:17PM +0900, Jean-Christophe Helary wrote:
>> 
>> 
>>> On Jun 8, 2019, at 22:30, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>> We have an enormously complex piece of software on
>>> our hands, and we have no better choice than going the "inconvenient"
>>> ways when we want to rebind an unusual key.
>> 
>> In all honesty:
>> 
>> (define-key input-decode-map "\C-[" [C-left-bracket])
>> (define-key global-map [C-left-bracket] 'myfunction)
>> 
>> is not inconvenient at all. What is inconvenient is the discovery process.
> 
> Then documentation is the way forward, perhaps?

I think so.

>> Knowing what I know about emacs (which is above the casual user) and even with the willingness to go through the manual, it would have been (it *has* been) impossible for me to find that solution.
>> 
>> Now, what I'd love to know is what are the other "unusual" keys, because as a group, they deserve a few more lines in the manual.
> 
> A good set of candidates would be all those control characters
> (the first 31 in man ascii(7)) which are customarily bound
> to a key (like CTRL-C, aka ETX, CTRL-\, aka FS, and so on).
> 
> Care to compile a list?

Sure. I'll try them and see if I can rebind them "normally" or if I have to use the above method.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sat, 8 Jun 2019 22:54:17 +0900
> 
> > We have an enormously complex piece of software on
> > our hands, and we have no better choice than going the "inconvenient"
> > ways when we want to rebind an unusual key.
> 
> In all honesty:
> 
> (define-key input-decode-map "\C-[" [C-left-bracket])
> (define-key global-map [C-left-bracket] 'myfunction)
> 
> is not inconvenient at all. What is inconvenient is the discovery process.

AFAIU, that discovery process, and the fact that you need 2 lines of
code rather than just one, was what was referred to as "inconvenient".

> Knowing what I know about emacs (which is above the casual user) and even with the willingness to go through the manual, it would have been (it *has* been) impossible for me to find that solution.

FWIW, I consider this not to be a catastrophe, far from it.  Emacs is
an enormously complex package, so it's impractical to require that
everything in it is immediately discoverable and easily customizable.
Especially when what you want to do is something as unusual as the
case in point.  I still hear every day one or two things I didn't know
about Emacs, after all those years of using, customizing, and hacking
it.  We could (and do) add stuff to the manuals and the doc strings,
but there's limit to how this could improve discoverability.  We
shouldn't expect, let alone demand, unreachable goals.

> Now, what I'd love to know is what are the other "unusual" keys, because as a group, they deserve a few more lines in the manual.

I suggest a careful reading of keymap.c and keyboard.c, the answer to
this question is there.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 9, 2019, at 0:42, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Sat, 8 Jun 2019 22:54:17 +0900
>> 
>>> We have an enormously complex piece of software on
>>> our hands, and we have no better choice than going the "inconvenient"
>>> ways when we want to rebind an unusual key.
>> 
>> In all honesty:
>> 
>> (define-key input-decode-map "\C-[" [C-left-bracket])
>> (define-key global-map [C-left-bracket] 'myfunction)
>> 
>> is not inconvenient at all. What is inconvenient is the discovery process.
> 
> AFAIU, that discovery process, and the fact that you need 2 lines of
> code rather than just one, was what was referred to as "inconvenient".

Ok, plenty of misunderstandings in this thread. Thank you for the clarification.

>> Knowing what I know about emacs (which is above the casual user) and even with the willingness to go through the manual, it would have been (it *has* been) impossible for me to find that solution.
> 
> FWIW, I consider this not to be a catastrophe, far from it.  Emacs is
> an enormously complex package, so it's impractical to require that
> everything in it is immediately discoverable and easily customizable.
> Especially when what you want to do is something as unusual as the
> case in point.  I still hear every day one or two things I didn't know
> about Emacs, after all those years of using, customizing, and hacking
> it.  We could (and do) add stuff to the manuals and the doc strings,
> but there's limit to how this could improve discoverability.  We
> shouldn't expect, let alone demand, unreachable goals.

Well, I ended up with a solution so I'm not calling anything discussed here a catastrophe.

But as far as "as unusual as the case in point", I have my left fourth finger close to Ctrl, and my right fourth finger close to [ and ], so what better combination could I think of when I need something that goes to the left and then to the right ? That might not occur to you because of your background, but for me, that binding was just urging me to be done...

>> Now, what I'd love to know is what are the other "unusual" keys, because as a group, they deserve a few more lines in the manual.
> 
> I suggest a careful reading of keymap.c and keyboard.c, the answer to
> this question is there.

Thank you !


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sun, 9 Jun 2019 09:52:09 +0900
> 
> But as far as "as unusual as the case in point", I have my left fourth finger close to Ctrl, and my right fourth finger close to [ and ], so what better combination could I think of when I need something that goes to the left and then to the right ?

< and > come to mind.  They are very near the [ and ] keys.  And on
some/many keyboards you also have the arrow keys nearby.

Re: Ctrl-[ ?

[Jean-Christophe Helary]

> On Jun 9, 2019, at 15:19, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Sun, 9 Jun 2019 09:52:09 +0900
>> 
>> But as far as "as unusual as the case in point", I have my left fourth finger close to Ctrl, and my right fourth finger close to [ and ], so what better combination could I think of when I need something that goes to the left and then to the right ?
> 
> < and > come to mind.  They are very near the [ and ] keys.  And on
> some/many keyboards you also have the arrow keys nearby.

< and > require a Shift on my keyboard, arrows are used to change work space. But yes, there are plenty of key pairs that can work, until one finds that they can't :)

On a side note, this is probably the most interesting thread I ever started here :) Lots of stuff to learn and lots of stuff to do too. Thank you all.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On Sat, Jun 08, 2019 at 04:30:14PM +0300, Eli Zaretskii wrote:
> > From: Óscar Fuentes <ofv@wanadoo.es>
> > Date: Sat, 08 Jun 2019 15:06:54 +0200
> > 
> > Nobody is asking for a change on the default bindings, what we are
> > saying it that the user should be allowed to set the binding the
> > same way he does for any other binding.
> 
> If you or someone else believe they know enough about the Emacs
> keyboard input processing to propose its redesign which will satisfy
> the above requirement [...]

> Current situation is nowhere near such expertise.  Suffices it to say
> that several times during the recent years when we needed to make
> seemingly-simple changes and fixes in that code, no one had the
> courage to approve such changes.  For some of them, it later turned
> out that we broke some subtle but important use cases, for others we
> still have our fingers crossed.  So please don't expect any
> significant redesigns in that any time soon, as long as all we do is
> vent steam here.  We have an enormously complex piece of software on
> our hands, and we have no better choice than going the "inconvenient"
> ways when we want to rebind an unusual key.

Well said. The only one stepping forward with some code was Stefan,
and personally, I find it a bit discouraging that folks just keep
saying what "Emacs Should Do" without investing much effort into
understanding what's there and what other users need/want.

Software development is a collective effort, and it takes listening
as well as talking, I think.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Ctrl-[ ?

[Óscar Fuentes]

<tomas@tuxteam.de> writes:

> On Sat, Jun 08, 2019 at 04:30:14PM +0300, Eli Zaretskii wrote:
>> > From: Óscar Fuentes <ofv@wanadoo.es>
>> > Date: Sat, 08 Jun 2019 15:06:54 +0200
>> > 
>> > Nobody is asking for a change on the default bindings, what we are
>> > saying it that the user should be allowed to set the binding the
>> > same way he does for any other binding.
>> 
>> If you or someone else believe they know enough about the Emacs
>> keyboard input processing to propose its redesign which will satisfy
>> the above requirement [...]

No, I don't know enough. I just looked at keyboard.c for several minutes
and can only understand your cautions about touching what it seems a
pile of bugfixes on top of a stack of hacks to deal with quirky
terminals shoehorning new paradigms like guis into a pre-existing
tty-based design. Oh, and the interactions with the display engine, as
if handling terminals were not complex enough on itself.

>> Current situation is nowhere near such expertise.  Suffices it to say
>> that several times during the recent years when we needed to make
>> seemingly-simple changes and fixes in that code, no one had the
>> courage to approve such changes.  For some of them, it later turned
>> out that we broke some subtle but important use cases, for others we
>> still have our fingers crossed.  So please don't expect any
>> significant redesigns in that any time soon, as long as all we do is
>> vent steam here.  We have an enormously complex piece of software on
>> our hands, and we have no better choice than going the "inconvenient"
>> ways when we want to rebind an unusual key.
>
> Well said. The only one stepping forward with some code was Stefan,
> and personally, I find it a bit discouraging

What I find discouraging is this phrase on the above quoted message:

>> ... Suffices it to say that several times during the recent years
>> when we needed to make seemingly-simple changes and fixes in that
>> code, no one had the courage to approve such changes.

I'm sure that that is not Eli's intention, but encouraging it is not.

> that folks just keep
> saying what "Emacs Should Do" without investing much effort into
> understanding what's there and what other users need/want.

Care to explain how the proposed change would take away from you?

> Software development is a collective effort, and it takes listening
> as well as talking, I think.

I listened as hard as I can, and still don't understand why you react
this way to this issue, when several times we explicitly said that
nothing would change on the default behavior.

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 08 Jun 2019 21:40:07 +0200
> 
> No, I don't know enough. I just looked at keyboard.c for several minutes
> and can only understand your cautions about touching what it seems a
> pile of bugfixes on top of a stack of hacks to deal with quirky
> terminals shoehorning new paradigms like guis into a pre-existing
> tty-based design.

That's a myth not really backed up by the code.

> Oh, and the interactions with the display engine, as if handling
> terminals were not complex enough on itself.

Another myth.

> >> ... Suffices it to say that several times during the recent years
> >> when we needed to make seemingly-simple changes and fixes in that
> >> code, no one had the courage to approve such changes.
> 
> I'm sure that that is not Eli's intention, but encouraging it is not.

It's how things are.  Whether they are encouraging or not depends on
what you intend to do about that.  If you want to change/improve it,
come aboard, study the code and its callers, and then redesign and
reimplement it.

Seriously, what did you expect from a 35-year old program that gives
its users an unprecedented amount of power to tweak its workings?  You
can call terminals "quirky" all you want, but they are all still very
much with us, and we must support them, the newer ones, the mouse, you
name it -- all in the same event queue, because that's how Lisp
programs expect to see the input events.

Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

On Sat, Jun 08, 2019 at 09:40:07PM +0200, Óscar Fuentes wrote:
> <tomas@tuxteam.de> writes:
> 
> > On Sat, Jun 08, 2019 at 04:30:14PM +0300, Eli Zaretskii wrote:

[...]

> > Well said. The only one stepping forward with some code was Stefan,
> > and personally, I find it a bit discouraging
> 
> What I find discouraging is this phrase on the above quoted message:
> 
> >> ... Suffices it to say that several times during the recent years
> >> when we needed to make seemingly-simple changes and fixes in that
> >> code, no one had the courage to approve such changes.
> 
> I'm sure that that is not Eli's intention, but encouraging it is not.

It's expected. Big software organisms are like that. Try hacking
on Mozilla, or Eclipse, or...

I think Emacs fares quite well compared to that, more so given its
age.

> > that folks just keep
> > saying what "Emacs Should Do" without investing much effort into
> > understanding what's there and what other users need/want.
> 
> Care to explain how the proposed change would take away from you?

I think I explained that twice. Won't repeat.

> > Software development is a collective effort, and it takes listening
> > as well as talking, I think.
> 
> I listened as hard as I can, and still don't understand why you react
> this way to this issue, when several times we explicitly said that
> nothing would change on the default behavior.

Sorry if I hurt you in any way.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Ctrl-[ ?

[Francis Belliveau]

> On Jun 7, 2019, at 20:31, Óscar Fuentes <ofv@wanadoo.es> wrote:
> 
> Francis Belliveau <f.belliveau@comcast.net> writes:
> 
>> I think that a lot of you are missing the point that was made early on
>> in the discussion. This mapping of ASCII cntrol characters is a
>> definition made by convention since the day of the Teletype machines.
>> It is how the ASCII character set was defined.
> 
> So what? Why a GUI user should be inconvenienced or prevented to bind
> C-i, C-[, etc. to whatever he pleases the same way he binds any other
> key combination? You can't bind C-[ on a terminal, because there is a
> technical limitation, ok. But why you can't bind it either on a GUI,
> where the technical limitation does not exist?
> 

There are many other emails on this discussion that I would like to respond to.  I chose this one because it is most blatantly missing the point that I am attempting to make.  I will try to answer all the comments that I can remember.  A lot of emails showed up while I was composing what I have below.

What I am trying to say is that the technical limitation does exist in a GUI application because the OS puts it there.

First I would like to say that I do not know much about the internals of the EMACS source code, but what I believe that Oscar is expressing below is the assumption that the EMACS application has direct access to the keyboard key bindings.  If that is the case, then something can certainly be done there to change how things work, but as was previously mentioned there may be some serious, and difficult to predict, side effects.

However, my development experience is that there are some bindings that are at the OS interface level and therefore invisible to the application.  It is possible that EMACS is using a lower-level keyboard interface that allows it to see raw keystrokes, but I would not have implemented things that way because it is very implementation dependent.  I have worked on interfacing directly to keyboard input and it can get very messy because it depends on the keyboard model that the keystrokes come from, and you need to handle every Key-Down and Key-Up along with "repeat actions" when keys are held down too long.  Think of what happens if you hold down the shift key long enough for the key-repeat to begin; the keyboard starts sending "shift-down" events at the "repeat rate" mixed in with any other key events that you perform while holding the shift key down.  It is far easier to let the OS drivers untangle all that.  Some keyboards come with customizable drivers these days that may allow you to remap things in a way that will help.

It is my assumption in what I say below that EMACS is trusting the OS to perform the keystroke translations for it.  If there is somebody who knows that the application source operates differently, I will abdicate to their greater knowledge.  But if you are assuming that I am wrong without that in-depth knowledge, then you are likely to be disappointed.

Let me begin with the "documentation" that was requested.  I deleted the original posting that contained the explanation of ASCII and how it works.  You will find reasonable documentation at
https://en.wikipedia.org/wiki/ASCII
There you will find that a few of the ASCII control-codes are mapped to actual keys on your keyboard.  I note those below.

Although ASCII is far from the only character set in use today, I believe that you will find that most character sets hold ASCII as the base that they are built upon.  This is because it is the first standard character set.
Character sets today come in different sizes, but ASCII only requires 7 bits, so even an 8-bit key-code can include a "meta" modifier indication.  A 16-bit character set can certainly do a lot more.

I believe that the next level of documentation that was requested is "which keys provide identical bindings?"  Every application I ever wrote to interface with keyboard input has assumed an 8-bit character set and therefore cannot tell the difference in the following key-strokes (using EMACS notation):

C-h = Backspace
C-I = Tab
C-j = Line-Feed
C-m = Carriage-Return
C-[ = Escape

Line-Feed and Carriage-Return are holdovers from how typewriters functioned.  Depending on the OS you may be able to rebind one, but likely not the other, in a manner that does not effect the function run when you use your "Enter" or "Return" key.  Please note that I speak only of the main keys on the keyboard.  Your extra "keypad(s)" will generally send escape-sequences, even for the "Enter" key that you will find there.

You will also notice that there is no control sequence available for what ASCII calls the Delete character and that C-h is mapped to Backspace.  On a QWERTY typewriter keyboard the Backspace key it at the upper right-hand corner where most of today's keyboards place what they call a Delete key.

When I use C-hk to ask EMACS for help with a keystroke sequence, I find that
C-[ = Escape, C-i = Tab and C-m = Enter, Delete = Backspace.  
I must admit that I am surprised that C-h and Backspace are actually seen differently, but the remainder holds up and the keyboards might actually be sending a Delete code that EMACS is calling Backspace.  
Furthermore, the "Enter" button is positioned on the keyboard where the Carriage-Return button was placed when electric typewriters were created.

So what I believe that many of you are complaining about is the inability to separate the actions by specialized keys on your keyboard from the "control code" that they actually generate.

What I am saying is that if EMACS cannot tell the difference, then it cannot provide you with the ability to bind them differently.  To fix the problem you will need to go deeper into things than just a simple key-mapping like what happens when you hit C-z.

Fran

Re: Ctrl-[ ?

[Óscar Fuentes]

Francis Belliveau <f.belliveau@comcast.net> writes:

[snip]

> However, my development experience is that there are some bindings
> that are at the OS interface level and therefore invisible to the
> application.

That's true, but it is not the case of the keybindings we are discussing
here. For security reasons, the OS does not pass certain keys to
applications (Ctrl+Alt+DEL on MS-Windows, for instance; AFAIK GNU-Linux
is more customizable on this aspect).

[exposition of how ASCII codes work on a terminal elided]

> So what I believe that many of you are complaining about is the
> inability to separate the actions by specialized keys on your keyboard
> from the "control code" that they actually generate.
>
> What I am saying is that if EMACS cannot tell the difference, then it
> cannot provide you with the ability to bind them differently. To fix
> the problem you will need to go deeper into things than just a simple
> key-mapping like what happens when you hit C-z.

GUIs are quite more sophisticated than what you explained. To begin
with, the GUI keyboard handling system does not work on ASCII, but on
key codes. (Since decades ago GUIs are expected to support non-ASCII
keyboards out of the box.) Also, it is possible to detect things such as
pressing the left or right Shift key (without combining it with another
key) or simultaneous presses of "printable" keys.

You can monitor those low-level events. The OS usually provides some
facilities to translate those events to higher level events. I don't
know at which level Emacs works for GUIs, probably the later. But that's
irrelevant, because Emacs can detect equally well C-[ as C-t, because
them come from the exact same mechanism, and no GUI I know of will
intercept a C-something key combination (some desktop environments, such
as KDE, define keybindings that overlap with with Emacs', quite
annoyingly, BTW, but the user is free from removing those KDE
keybindings).

In short, thinking about this issue on terms of ttys is missing the
point, because the key here (pun intended) is, precisely, that GUIs have
a keyboard handling model that has nothing to do with ttys and are not
subject to their limitations.

Re: Ctrl-[ ?

[Stefan Monnier]

> You can monitor those low-level events. The OS usually provides some
> facilities to translate those events to higher level events. I don't
> know at which level Emacs works for GUIs, probably the later. But that's
> irrelevant, because Emacs can detect equally well C-[ as C-t, because

Indeed, as my sample patch shows.

Currently, the core of the "hardcoding" happens in `make_ctrl_char` (in
src/keyboard.c) where we compute an "event with control modifier":
rather than just set to `control` bit on integer events (Emacs
distinguishes events made of "a character plus some modifiers", which
are represented as integers where some bits are used for the modifiers,
from non-character events like `tab`, `next`, `f1, etc which are
represented as symbols instead), we sometimes set the control bit and
sometimes change the char into an "ASCII control char".  That's where
"control plus [" is turned into the "ASCII C-[" char which is also
known as ESC (aka code 27).

The core of my patch disables this special case, so instead we always
just set the "control modifier bit" (which is bit 26).

The hard work comes afterwards, because we then need to figure out what
to do with all the parts of Emacs where we previously used code 1 (the
ASCII C-a) instead of code 97 + 2^26 (the combination of the letter `a`
and the control modifier bit).

E.g. part of my patch changes the way we print those.  E.g. the current
Emacs code describes both events identically:

    (single-key-description (+ 97 (ash 1 26)))  => "C-a"
    (single-key-description 1)                  => "C-a"

Which makes debugging these things harder, so my patch changes this (it
changes it by printing "\^a" for the second).

But there are various other related issues.  E.g. when we have `?\C-m`
in Elisp code, should the reader consider it as (+ ?m (ash 1 26)) or
as 13?  In terms of backward compatibility, there's actually not much
choice: it has to be 13 otherwise lots of code will break (because this
`?\C-m` is really meant to represent the RET character and if we turn
it into (+ ?m (ash 1 26)) we get something that's not even a valid
character (it can't be put inside a string or buffer)).  But then we
need a new syntax for "the `m` char combined with the control modifier".


        Stefan

Re: Ctrl-[ ?

[Óscar Fuentes]

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

> Indeed, as my sample patch shows.
>
> Currently, the core of the "hardcoding" happens in `make_ctrl_char` (in
> src/keyboard.c) where we compute an "event with control modifier":
> rather than just set to `control` bit on integer events (Emacs
> distinguishes events made of "a character plus some modifiers", which
> are represented as integers where some bits are used for the modifiers,
> from non-character events like `tab`, `next`, `f1, etc which are
> represented as symbols instead), we sometimes set the control bit and
> sometimes change the char into an "ASCII control char".  That's where
> "control plus [" is turned into the "ASCII C-[" char which is also
> known as ESC (aka code 27).
>
> The core of my patch disables this special case, so instead we always
> just set the "control modifier bit" (which is bit 26).
>
> The hard work comes afterwards, because we then need to figure out what
> to do with all the parts of Emacs where we previously used code 1 (the
> ASCII C-a) instead of code 97 + 2^26 (the combination of the letter `a`
> and the control modifier bit).
>
> E.g. part of my patch changes the way we print those.  E.g. the current
> Emacs code describes both events identically:
>
>     (single-key-description (+ 97 (ash 1 26)))  => "C-a"
>     (single-key-description 1)                  => "C-a"
>
> Which makes debugging these things harder, so my patch changes this (it
> changes it by printing "\^a" for the second).
>
> But there are various other related issues.  E.g. when we have `?\C-m`
> in Elisp code, should the reader consider it as (+ ?m (ash 1 26)) or
> as 13?  In terms of backward compatibility, there's actually not much
> choice: it has to be 13 otherwise lots of code will break (because this
> `?\C-m` is really meant to represent the RET character and if we turn
> it into (+ ?m (ash 1 26)) we get something that's not even a valid
> character (it can't be put inside a string or buffer)).  But then we
> need a new syntax for "the `m` char combined with the control modifier".

Thank you for the detailed explanation. IIUC the delicate part consists
on locating and deciding what's the right thing to do about each of
those uses of "control characters" scattered through the code base.

Re: Ctrl-[ ?

[Stefan Monnier]

> Thank you for the detailed explanation. IIUC the delicate part consists
> on locating and deciding what's the right thing to do about each of
> those uses of "control characters" scattered through the code base.

Not really, no.  We can't go and change each place, because many of the
places are outside of our control.
So rather, we have to find a clever way to keep the old code working as
before while still adding the new feature.

Using my proof-of-concept code, I see one of the major problems:

- We need some way to tell define-key whether we want to add a binding
  to ^x (the ASCII control char) or to C-x (the combination of control
  with `x`), same with TAB (aka ^i) -vs- C-i, ESC (aka ^[) -vs- C-[, etc...

- Once we do that we have another problem:
  Say your favorite major mode binds ^x ^x to FOO
  And say some new package adds a global binding for C-x C-x to BAR.
  Now the global binding takes precedence over the buffer-local binding
  from your favorite major mode :-(


-- Stefan

Re: Ctrl-[ ?

[Francis Belliveau]

> On Jun 8, 2019, at 20:25, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> You can monitor those low-level events. The OS usually provides some
>> facilities to translate those events to higher level events. I don't
>> know at which level Emacs works for GUIs, probably the later. But that's
>> irrelevant, because Emacs can detect equally well C-[ as C-t, because
> 
> Indeed, as my sample patch shows.
> 
> Currently, the core of the "hardcoding" happens in `make_ctrl_char` (in
> src/keyboard.c) where we compute an "event with control modifier":
> rather than just set to `control` bit on integer events (Emacs
> distinguishes events made of "a character plus some modifiers", which
> are represented as integers where some bits are used for the modifiers,
> from non-character events like `tab`, `next`, `f1, etc which are
> represented as symbols instead), we sometimes set the control bit and
> sometimes change the char into an "ASCII control char".  That's where
> "control plus [" is turned into the "ASCII C-[" char which is also
> known as ESC (aka code 27).
> 
> The core of my patch disables this special case, so instead we always
> just set the "control modifier bit" (which is bit 26).
> 
> The hard work comes afterwards, because we then need to figure out what
> to do with all the parts of Emacs where we previously used code 1 (the
> ASCII C-a) instead of code 97 + 2^26 (the combination of the letter `a`
> and the control modifier bit).
> 
[snip]

Thank you Stefan for the enlightenment.  I did say that I have never looked into the source code.
Given what you say, I am curious why C-h is not known as Backspace.  Whatever special handling is done there could be able to be applied to C- and C-[.

Another possibility is that since your patch was applied to all keys, maybe it should only check for "special" keys, like these two.  That would certainly reduce side effects like you mention.

Either way the next step would be to make people like me happy and provide a default binding that undoes the patch.  
Since this discussion began, I started taking notice of how often I use these short-cuts.  I actually caught myself using the sequence C-pC-i today to fix indentation on a couple of lines.  I also seem to use C-[C-\ a lot because it eliminates the need for me to change modifier-fingering.

Whatever you decide I would hope that those of us who frequently use these mappings will not need to add a lot of new mappings after upgrade in order to fix back what we are used to doing.

Just my opinion.

Fran

Re: Ctrl-[ ?

[Stefan Monnier]

> Thank you Stefan for the enlightenment.  I did say that I have never
> looked into the source code.  Given what you say, I am curious why C-h
> is not known as Backspace.

There are always 3 entities at play here:

    ASCII-control  |  GUI key   |  GUI control-modified-key
    ---------------------------------------------------
       TAB         |  tab       |  control i
       ESC         |  escape    |  control [
       RET         |  return    |  control m
       LF          |  linefeed  |  control j
       ...

And in Emacs, the mapping from the 3rd column to the 1st is hardcoded in
make_ctrl_char while the mapping from the 2nd to the first is
implemented in function-key-map, which can be easily overridden by the
end-user.

for "backspace" the situation is affected by the fact that some
text-terminal sent "EFF" (aka C-h) for the backspace key while others
sent DEL (aka C-? but it is really the code 127).  Overtime, the C-?
camp won, so Emacs kind of uses:

       DEL         |  backspace | control ?

except that it seems the mapping from "control ?" to DEL is not
hardcoded in the same way so `C-h k C-?` doesn't bring you to the
key binding of DEL.

> Another possibility is that since your patch was applied to all keys, maybe
> it should only check for "special" keys, like these two.  That would
> certainly reduce side effects like you mention.

Indeed.

> Either way the next step would be to make people like me happy and provide
> a default binding that undoes the patch.
> Since this discussion began, I started taking notice of how often I use
> these short-cuts.  I actually caught myself using the sequence C-pC-i today
> to fix indentation on a couple of lines.  I also seem to use C-[C-\ a lot
> because it eliminates the need for me to change modifier-fingering.

If we ever implement a change similar to the proof-of-concept patch
I sent, then of course it would strive to not modify the default
behavior, except maybe in some hard-to-cover corner cases.


        Stefan

[offtopic] Re: Ctrl-[ ?

[Van L]

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

> There are always 3 entities at play here:
>
>     ASCII-control  |  GUI key   |  GUI control-modified-key
>     ---------------------------------------------------
>        TAB         |  tab       |  control i
>        ESC         |  escape    |  control [
>        RET         |  return    |  control m
>        LF          |  linefeed  |  control j
>        ...

The fingering for column-3 with thumb over space
is natural and comfy.

Using the keyboard on the Lenovo Thinkpad A485 as
reference and right shifting the right palm such
that the thumb is over each of the three modifier
keys with fingerings also right shifting has potential for smooth ergonomical
transition from right handed mouse to keying
combinations with one hand on the right side of
the keyboard.



-- 
© 2019 Van L
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
           "you have to be Albert Einstein to figure it out" - Donald J. Trump

Re: [offtopic] Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

On Fri, Jun 14, 2019 at 10:06:29PM +1000, Van L wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > There are always 3 entities at play here:
> >
> >     ASCII-control  |  GUI key   |  GUI control-modified-key
> >     ---------------------------------------------------
> >        TAB         |  tab       |  control i
> >        ESC         |  escape    |  control [
> >        RET         |  return    |  control m
> >        LF          |  linefeed  |  control j
> >        ...
> 
> The fingering for column-3 with thumb over space
> is natural and comfy.
> 
> Using the keyboard on the Lenovo Thinkpad A485 as
> reference and right shifting the right palm such
> that the thumb is over each of the three modifier
> keys with fingerings also right shifting has potential for smooth ergonomical
> transition from right handed mouse to keying
> combinations with one hand on the right side of
> the keyboard.

Until you've got a German keyboard layout, where you need yet
another modifier (AltGr) to reach [, ], \ and |.

I'm sure there are multitude of other language-specific keyboard
layouts sharing that weakness...

But I didn't want to open /that/ can o' worms -- just to raise
a bit of awareness.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [offtopic] Re: Ctrl-[ ?

[Van L]

<tomas@tuxteam.de> writes:

> Until you've got a German keyboard layout, where you need yet
> another modifier (AltGr) to reach [, ], \ and |.

Choose the keys comfy for you relative to thumb over modifier key and
finger tips poised to strike like in a DOOM Eternal Deathmatch.

> I'm sure there are multitude of other language-specific keyboard
> layouts sharing that weakness...

Localise the layout.

> But I didn't want to open /that/ can o' worms -- just to raise
> a bit of awareness.

I don't have the luxury of 3 modifier keys right of my spacebar and have
the following experimental layout.  The CAPSLOCK 'on' doesn't function
like holding the SHIFT key down for, for example, '(kbd "H-S-l")'.

--8<---------------cut here---------------start------------->8---
(global-set-key (kbd "H-[") 'recenter-top-bottom)

(global-set-key (kbd "H-p") 'left-char)
(global-set-key (kbd "H-\\") 'right-char)
(global-set-key (kbd "H-C-p") 'move-beginning-of-line)
(global-set-key (kbd "H-C-\\") 'move-end-of-line)

(define-key global-map (kbd "H-l") 'previous-line)
(define-key global-map (kbd "H-.") 'next-line)
(define-key global-map (kbd "H-C-l") 'backward-paragraph)
(define-key global-map (kbd "H-C-.") 'forward-paragraph)

--8<---------------cut here---------------end--------------->8---


-- 
© 2019 VanL
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
          'The mouth is the dirtiest part on the human body.' - Bill Wallace

Re: [offtopic] Re: Ctrl-[ ?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

On Sat, Jun 15, 2019 at 07:12:28PM +1000, Van L wrote:
> <tomas@tuxteam.de> writes:
> 
> > Until you've got a German keyboard layout, where you need yet
> > another modifier (AltGr) to reach [, ], \ and |.
> 
> Choose the keys comfy for you relative to thumb over modifier key and
> finger tips poised to strike like in a DOOM Eternal Deathmatch.

It's more complicated than that: on the one hand, there's a strong
incentive for /one/ default set of keybindings (a baseline, so to
speak): documentation, tutorials, help forums, etc. (imagine you had
to parametrize them with $deity-knows-what-weird-keybinding-set, they'd
spread pretty thinly).

> > I'm sure there are multitude of other language-specific keyboard
> > layouts sharing that weakness...
> 
> Localise the layout.

See above. I think, realistically, that a non-standard layout is
(except maybe a few exceptions) a difficult balance act. More than
it seems at first blush: a key binding set is, after all, like a
new language -- you get a "tower of Babel" effect if you multiply
that.

Now I'm not arguing against using the flexibility Emacs provides
here, quite on the contrary. I'm just stating that it doesn't come
at zero cost (on the "social" side).

> > But I didn't want to open /that/ can o' worms -- just to raise
> > a bit of awareness.
> 
> I don't have the luxury of 3 modifier keys right of my spacebar and have
> the following experimental layout.  The CAPSLOCK 'on' doesn't function
> like holding the SHIFT key down for, for example, '(kbd "H-S-l")'.

Yeah, I've some little tweaks on my keyboard too (most of them at the
X level, because I like my apps to behave consistently). The (useless [1])
CAPSLOCK does compose, so I can write ♥ (= CAPSLOCK + < + 3) and other
trivia. Double-shift changes my keyboard to Greek input.

But when I'm discussing with some other Emacs person across the world
what CTRL-/ does (-> undo), the fact that, for me, it's unergonomic
(CTR-SHIFT-7) and for her it's just a two-key combo, is perhaps not
so important. Or it is. As I said, can of worms.

I don't think there's "a solution" to that. It helps being aware of
the multitude of factors involved.

Cheers

[1] See? Some might consider CAPSLOCK INDISPENSABLE. And they'd right
   too :-)

-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [offtopic] Re: Ctrl-[ ?

[Van L]

<tomas@tuxteam.de> writes:

> On Sat, Jun 15, 2019 at 07:12:28PM +1000, Van L wrote:
>> Choose the keys comfy for you relative to thumb over modifier key and
>> finger tips poised to strike like in a DOOM Eternal Deathmatch.
>
> It's more complicated than that: on the one hand, there's a strong
> incentive for /one/ default set of keybindings (a baseline, so to
> speak): documentation, tutorials, help forums, etc. (imagine you had
> to parametrize them with $deity-knows-what-weird-keybinding-set, they'd
> spread pretty thinly).

I don't know waht is the proper meaning of the Hyper or Super key
modifier in relation to Emacs. Assuming they are meaningless, using
those don't interfere with the legacy /one/ default set of keybindings.

>> > I'm sure there are multitude of other language-specific keyboard
>> > layouts sharing that weakness...
>> 
>> Localise the layout.
>
> See above. I think, realistically, that a non-standard layout is
> (except maybe a few exceptions) a difficult balance act. More than
> it seems at first blush: a key binding set is, after all, like a
> new language -- you get a "tower of Babel" effect if you multiply
> that.

The TCP/IP stack is a 5 or 7 layer tower of babel :-)

My feeling is if you have 50 Emacs people who love Emacs in a boundary
of 50 million people who use Emacs, and the 50 million people can vote
on the most natural comfy feeling layout, which happens to select those
50 people's layout in the first place, the distribution should be big
enough to let users choose from those layouts.

> Now I'm not arguing against using the flexibility Emacs provides
> here, quite on the contrary. I'm just stating that it doesn't come
> at zero cost (on the "social" side).
>
>> > But I didn't want to open /that/ can o' worms -- just to raise
>> > a bit of awareness.
>> 
>> I don't have the luxury of 3 modifier keys right of my spacebar and have
>> the following experimental layout.  The CAPSLOCK 'on' doesn't function
>> like holding the SHIFT key down for, for example, '(kbd "H-S-l")'.
>
... [snip]
>
> I don't think there's "a solution" to that. It helps being aware of
> the multitude of factors involved.

                            [ ¯\\_(ツ)_/¯ ]

nuff said

-- 
© 2019 VanL
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
          'The mouth is the dirtiest part on the human body.' - Bill Wallace

Re: Ctrl-[ ?

[Eli Zaretskii]

> From: Francis Belliveau <f.belliveau@comcast.net>
> Date: Sat, 8 Jun 2019 17:03:06 -0400
> 
> It is my assumption in what I say below that EMACS is trusting the OS to perform the keystroke translations for it.

This is only correct up to a point.  Modern GUI environments allow
Emacs to distinguish between, say, Delete the function key and DEL the
ASCII octal 177 code.  They also allow it to distinguish between an
ASCII key pressed together with Ctrl and the corresponding lower ASCII
control code.  Emacs does the conversion to conflate those, at least
by default, because otherwise most users will be flabbergasted to
learn that, say, C-[ doesn't produce the same effect as ESC.

Documenting these conversion is not easy, because many of them have to
do with deep internals of character and key representation in various
parts of Emacs.  For example, Ctrl and Meta modifiers have 2 different
representations, and Emacs by default goes out of its way to hide this
difference.