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

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