bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Dima Kogan]

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

Hi.

I noticed that on some platforms the caps-lock state can affect how key
chords are interpreted. It is currently inconsistent across platforms.
The behavior that feels correct to me is that caps-lock should affect
the case of letters as they are typed, and NOTHING else.

On gtk, if caps-lock is ON then Control+s produces C-S-s and
Control+Shift+s produces C-s; this is backwards from what I think it
should do.

On OSX it looks like with caps-lock, both shifted and non-shifted
presses produce C-s, which is 50% wrong regardless of how one thinks
this SHOULD work.

On Windows it does the right thing.

In a console on Debian it looks like Control+Shift+s produces C-s
regardless of caps-lock, but I suspect this has a deeper cause than what
this patch touches.


I have tested this patch on gtk (fixes it) and the console (doesn't
change anything). Hopefully it makes osx work properly while letting
windows builds keep working.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch --]
[-- Type: text/x-diff, Size: 2143 bytes --]

From 7e34d122ff981c4a9eb671aa2400efbf65144506 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@secretsauce.net>
Date: Sat, 17 Sep 2016 23:47:48 -0700
Subject: [PATCH] Caps-lock doesn't affect interpretation of key chords

* src/keyboard.c (make_lispy_event): when a user pressed key-chords the
caps-lock no longer affects the "shift" state of the generated chord.  For
instance Control+s produces C-s regardless of the caps-lock state.  And
Control+Shift+s produces C-S-s regardless of the caps-lock state.
---
 src/keyboard.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/src/keyboard.c b/src/keyboard.c
index b8bc361..a977de5 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5415,6 +5415,32 @@ make_lispy_event (struct input_event *event)
 	EMACS_INT c = event->code;
 	if (event->kind == ASCII_KEYSTROKE_EVENT)
 	  {
+            /* Caps-lock shouldn't affect interpretation of key chords:
+               Control+s should produce C-s whether caps-lock is on or
+               not.  And Control+Shift+s should produce C-S-s whether
+               caps-lock is on or not. */
+            if (event->modifiers & ~shift_modifier)
+              {
+                /* this is a key chord: some non-shift modifier is
+                   depressed */
+
+                if ('A' <= c && c <= 'Z' &&
+                    !(event->modifiers & shift_modifier) )
+                  {
+                    /* Got a capital letter without a shift.  The caps
+                       lock is on.   Un-capitalize the letter */
+                    c |= (unsigned)('a' - 'A');
+                  }
+                else if (('a' <= c && c <= 'z') &&
+                         (event->modifiers & shift_modifier) )
+                  {
+                    /* Got a lower-case letter even though shift is
+                       depressed.  The caps lock is on.  Capitalize the
+                       letter */
+                    c &= ~(unsigned)('a' - 'A');
+                  }
+              }
+
 	    c &= 0377;
 	    eassert (c == event->code);
 	    /* Turn ASCII characters into control characters
-- 
2.9.3

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[npostavs]

forcemerge 4931 24456
quit

Dima Kogan <dima@secretsauce.net> writes:
>
> In a console on Debian it looks like Control+Shift+s produces C-s
> regardless of caps-lock, but I suspect this has a deeper cause than what
> this patch touches.

Yeah, I think for terminals the keystrokes have to fit in bytes, so
there is no room for both a Ctrl and Shift bit to be set.

>
>
> I have tested this patch on gtk (fixes it) and the console (doesn't
> change anything). Hopefully it makes osx work properly while letting
> windows builds keep working.

After applying the patch to emacs-25, I built --with-x-toolkit=lucid and
--enable-checking; I get an assertion violation when hitting C-n with
capslock on.

In GNU Emacs 25.1.28 (x86_64-unknown-linux-gnu, X toolkit)
 of 2016-09-18 built on zony
Repository revision: 76981c4457682ae8699789b334a3be7b60ad301d
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
Configured using:
 'configure --cache-file=../debug-config.cache 'CFLAGS=-O0 -g3
 -march=native' --enable-checking MAKEINFO=makeinfo-4.13a
 --with-x-toolkit=lucid --without-toolkit-scroll-bars --with-gif=no
 --with-jpeg=no'

#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:354
#1  0x00000000005fa996 in die (msg=0x7273e6 "c == event->code", file=0x7259b0 "keyboard.c", line=5415)
    at alloc.c:7223
#2  0x000000000057d40e in make_lispy_event (event=0xd2ab68 <kbd_buffer+2632>) at keyboard.c:5415
#3  0x000000000057a2e3 in kbd_buffer_get_event (kbp=0x7fffffffddc8, used_mouse_menu=0x7fffffffe3af, 
    end_time=0x0) at keyboard.c:4071
#4  0x000000000057514a in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffe170, 
    used_mouse_menu=0x7fffffffe3af) at keyboard.c:2148
#5  0x0000000000575410 in read_decoded_event_from_main_queue (end_time=0x0, 
    local_getcjmp=0x7fffffffe170, prev_event=0, used_mouse_menu=0x7fffffffe3af) at keyboard.c:2211
#6  0x0000000000576fa7 in read_char (commandflag=1, map=28530083, prev_event=0, 
    used_mouse_menu=0x7fffffffe3af, end_time=0x0) at keyboard.c:2799
#7  0x0000000000585fe3 in read_key_sequence (keybuf=0x7fffffffe560, bufsize=30, prompt=0, 
    dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, 
    prevent_redisplay=false) at keyboard.c:9089
#8  0x00000000005730f0 in command_loop_1 () at keyboard.c:1365
#9  0x000000000061a8c2 in internal_condition_case (bfun=0x572cb4 <command_loop_1>, handlers=19056, 
    hfun=0x572346 <cmd_error>) at eval.c:1309
#10 0x00000000005728f6 in command_loop_2 (ignore=0) at keyboard.c:1107
#11 0x0000000000619e91 in internal_catch (tag=45840, func=0x5728cd <command_loop_2>, arg=0)
    at eval.c:1074
#12 0x0000000000572898 in command_loop () at keyboard.c:1086
#13 0x0000000000571e36 in recursive_edit_1 () at keyboard.c:692
#14 0x0000000000572036 in Frecursive_edit () at keyboard.c:763
#15 0x000000000056fde3 in main (argc=2, argv=0x7fffffffe9f8) at emacs.c:1626

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Date: Sun, 18 Sep 2016 00:01:23 -0700
> 
> diff --git a/src/keyboard.c b/src/keyboard.c
> index b8bc361..a977de5 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -5415,6 +5415,32 @@ make_lispy_event (struct input_event *event)
>  	EMACS_INT c = event->code;
>  	if (event->kind == ASCII_KEYSTROKE_EVENT)
>  	  {
> +            /* Caps-lock shouldn't affect interpretation of key chords:
> +               Control+s should produce C-s whether caps-lock is on or
> +               not.  And Control+Shift+s should produce C-S-s whether
> +               caps-lock is on or not. */
> +            if (event->modifiers & ~shift_modifier)
> +              {
> +                /* this is a key chord: some non-shift modifier is
> +                   depressed */
> +
> +                if ('A' <= c && c <= 'Z' &&
> +                    !(event->modifiers & shift_modifier) )
> +                  {
> +                    /* Got a capital letter without a shift.  The caps
> +                       lock is on.   Un-capitalize the letter */
> +                    c |= (unsigned)('a' - 'A');
> +                  }
> +                else if (('a' <= c && c <= 'z') &&
> +                         (event->modifiers & shift_modifier) )
> +                  {
> +                    /* Got a lower-case letter even though shift is
> +                       depressed.  The caps lock is on.  Capitalize the
> +                       letter */
> +                    c &= ~(unsigned)('a' - 'A');
> +                  }
> +              }
> +

Doesn't this mean that ASCII keys will behave differently from
non-ASCII when Caps Lock is ON?

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Dima Kogan]

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

npostavs@users.sourceforge.net writes:

> After applying the patch to emacs-25, I built --with-x-toolkit=lucid and
> --enable-checking; I get an assertion violation when hitting C-n with
> capslock on.

Thanks for testing. I didn't realize that assertions are disabled by
default. Fixed patch attached.


Eli Zaretskii writes:

> Doesn't this mean that ASCII keys will behave differently from
> non-ASCII when Caps Lock is ON?

If you're talking about characters used in non-English languages, then I
really have no idea what the current behavior is, or how to test it. I'm
hoping one of yall who actually use these languages will tell me.

dima


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch --]
[-- Type: text/x-diff, Size: 2143 bytes --]

From 66510839464f0efdc625790f3e64091012408dda Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@secretsauce.net>
Date: Sat, 17 Sep 2016 23:47:48 -0700
Subject: [PATCH] Caps-lock doesn't affect interpretation of key chords

* src/keyboard.c (make_lispy_event): when a user pressed key-chords the
caps-lock no longer affects the "shift" state of the generated chord.  For
instance Control+s produces C-s regardless of the caps-lock state.  And
Control+Shift+s produces C-S-s regardless of the caps-lock state.
---
 src/keyboard.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/src/keyboard.c b/src/keyboard.c
index b8bc361..cd8413b 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5417,6 +5417,33 @@ make_lispy_event (struct input_event *event)
 	  {
 	    c &= 0377;
 	    eassert (c == event->code);
+
+            /* Caps-lock shouldn't affect interpretation of key chords:
+               Control+s should produce C-s whether caps-lock is on or
+               not.  And Control+Shift+s should produce C-S-s whether
+               caps-lock is on or not. */
+            if (event->modifiers & ~shift_modifier)
+              {
+                /* this is a key chord: some non-shift modifier is
+                   depressed */
+
+                if ('A' <= c && c <= 'Z' &&
+                    !(event->modifiers & shift_modifier) )
+                  {
+                    /* Got a capital letter without a shift.  The caps
+                       lock is on.   Un-capitalize the letter */
+                    c |= (unsigned)('a' - 'A');
+                  }
+                else if (('a' <= c && c <= 'z') &&
+                         (event->modifiers & shift_modifier) )
+                  {
+                    /* Got a lower-case letter even though shift is
+                       depressed.  The caps lock is on.  Capitalize the
+                       letter */
+                    c &= ~(unsigned)('a' - 'A');
+                  }
+              }
+
 	    /* Turn ASCII characters into control characters
 	       when proper.  */
 	    if (event->modifiers & ctrl_modifier)
-- 
2.9.3

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[npostavs]

Dima Kogan <dima@secretsauce.net> writes:

> npostavs@users.sourceforge.net writes:
>
>> After applying the patch to emacs-25, I built --with-x-toolkit=lucid and
>> --enable-checking; I get an assertion violation when hitting C-n with
>> capslock on.
>
> Thanks for testing. I didn't realize that assertions are disabled by
> default. Fixed patch attached.

New patch works well.

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 24456@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 18 Sep 2016 11:25:46 -0700
> 
> Eli Zaretskii writes:
> 
> > Doesn't this mean that ASCII keys will behave differently from
> > non-ASCII when Caps Lock is ON?
> 
> If you're talking about characters used in non-English languages, then I
> really have no idea what the current behavior is, or how to test it. I'm
> hoping one of yall who actually use these languages will tell me.

I don't understand what you mean by that.  The effect of Caps Lock on
non-ASCII letters is clear: to produce the upper-case variant of the
letter.

My point is that treating ASCII letters differently from non-ASCII in
this regard should not be taken lightly.  We should at least discuss
whether the results are acceptable.

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> If you're talking about characters used in non-English languages, then I
>> really have no idea what the current behavior is, or how to test it. I'm
>> hoping one of yall who actually use these languages will tell me.
>
> I don't understand what you mean by that.  The effect of Caps Lock on
> non-ASCII letters is clear: to produce the upper-case variant of the
> letter.
>
> My point is that treating ASCII letters differently from non-ASCII in
> this regard should not be taken lightly.  We should at least discuss
> whether the results are acceptable.

I just meant that as someone who uses English almost exclusively, I
don't ordinarily encounter wide chars and unicode, and I don't know how
they apply here. The hope was that somebody who IS familiar with
non-English keyboards would point out the shortcomings, and would know
how to address them. Eli, do you know how caps-lock works on foreign
keyboards?

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: npostavs@users.sourceforge.net, 24456@debbugs.gnu.org
> Date: Sun, 18 Sep 2016 22:22:09 -0700
> 
> Eli, do you know how caps-lock works on foreign keyboards?

They capitalize letters, AFAIK.  Of course, the effect also depends on
the OS and the application that receives the keys.

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <dima@secretsauce.net>
>> Cc: npostavs@users.sourceforge.net, 24456@debbugs.gnu.org
>> Date: Sun, 18 Sep 2016 22:22:09 -0700
>> 
>> Eli, do you know how caps-lock works on foreign keyboards?
>
> They capitalize letters, AFAIK.  Of course, the effect also depends on
> the OS and the application that receives the keys.

OK. So how do we test this? The current patch fixes the ASCII case and
has no effect on the non-ASCII case. Maybe this is OK, actually, since
the only potentially broken remaining cases are with people binding
things like C-ó.

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: npostavs@users.sourceforge.net, 24456@debbugs.gnu.org
> Date: Mon, 19 Sep 2016 11:15:37 -0700
> 
> The current patch fixes the ASCII case and has no effect on the
> non-ASCII case. Maybe this is OK, actually, since the only
> potentially broken remaining cases are with people binding things
> like C-ó.

The likes of C-ó and M-ó is precisely what I'm worried about.  I don't
think it's right to support only ASCII letters in this use case.  We
should support the non-ASCII letters as well.

What exactly requires testing for ASCII lower-case letters in your
patch?  Why only ASCII?

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

> What exactly requires testing for ASCII lower-case letters in your
> patch?  Why only ASCII?

I'm trying to detect the caps-lock by finding capital letters that were
produced without Shift (and vice versa). I can do something like

  !shift_pressed && isupper(c)

but that doesn't work with wide characters. There's iswupper(c). Are the
wide chars it takes the same ones we get in that function? How about
non-latin scripts? Fundamentally I'm the worst person to be testing
this, sadly.

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: npostavs@users.sourceforge.net, 24456@debbugs.gnu.org
> Date: Mon, 19 Sep 2016 13:28:56 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What exactly requires testing for ASCII lower-case letters in your
> > patch?  Why only ASCII?
> 
> I'm trying to detect the caps-lock by finding capital letters that were
> produced without Shift (and vice versa). I can do something like
> 
>   !shift_pressed && isupper(c)
> 
> but that doesn't work with wide characters. There's iswupper(c). Are the
> wide chars it takes the same ones we get in that function? How about
> non-latin scripts?

We already have an inline function 'uppercasep', which you could use;
it supports any character that Emacs supports.

> Fundamentally I'm the worst person to be testing this, sadly.

Once the code is written, we can ask people to test it in different
locales, I don't expect problems in this area.

Thanks.

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Dima Kogan]

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

Eli Zaretskii <eliz@gnu.org> writes:

> We already have an inline function 'uppercasep', which you could use;
> it supports any character that Emacs supports.

OK. In that case, how about the attached patch? Tested working on gtk.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch --]
[-- Type: text/x-diff, Size: 2102 bytes --]

From 2b81504e1f34fed36c5ec1ee95dbceaf8df9d321 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@secretsauce.net>
Date: Sat, 17 Sep 2016 23:47:48 -0700
Subject: [PATCH] Caps-lock doesn't affect interpretation of key chords

* src/keyboard.c (make_lispy_event): when a user pressed key-chords the
caps-lock no longer affects the "shift" state of the generated chord.  For
instance Control+s produces C-s regardless of the caps-lock state.  And
Control+Shift+s produces C-S-s regardless of the caps-lock state.
---
 src/keyboard.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/src/keyboard.c b/src/keyboard.c
index b8bc361..ed0d9db 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5417,6 +5417,33 @@ make_lispy_event (struct input_event *event)
 	  {
 	    c &= 0377;
 	    eassert (c == event->code);
+
+            /* Caps-lock shouldn't affect interpretation of key chords:
+               Control+s should produce C-s whether caps-lock is on or
+               not.  And Control+Shift+s should produce C-S-s whether
+               caps-lock is on or not. */
+            if (event->modifiers & ~shift_modifier)
+              {
+                /* this is a key chord: some non-shift modifier is
+                   depressed */
+
+                if (uppercasep(c) &&
+                    !(event->modifiers & shift_modifier) )
+                  {
+                    /* Got a capital letter without a shift.  The caps
+                       lock is on.   Un-capitalize the letter */
+                    c = downcase(c);
+                  }
+                else if (lowercasep(c) &&
+                         (event->modifiers & shift_modifier) )
+                  {
+                    /* Got a lower-case letter even though shift is
+                       depressed.  The caps lock is on.  Capitalize the
+                       letter */
+                    c = upcase(c);
+                  }
+              }
+
 	    /* Turn ASCII characters into control characters
 	       when proper.  */
 	    if (event->modifiers & ctrl_modifier)
-- 
2.9.3

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: npostavs@users.sourceforge.net, 24456@debbugs.gnu.org
> Date: Wed, 21 Sep 2016 16:30:21 -0700
> 
> > We already have an inline function 'uppercasep', which you could use;
> > it supports any character that Emacs supports.
> 
> OK. In that case, how about the attached patch? Tested working on gtk.

Thanks.  However, this doesn't look right to me: your code is entirely
inside the following condition:

	if (event->kind == ASCII_KEYSTROKE_EVENT)

So it will not do anything for non-ASCII keystrokes.  You should move
the code out of that condition, I think.

> +                if (uppercasep(c) &&
> +                    !(event->modifiers & shift_modifier) )

A nit: our coding standards request a space between the function name
and the opening parenthesis that follows it, and no spaces between
closing parentheses.

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Dima Kogan]

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

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks.  However, this doesn't look right to me: your code is entirely
> inside the following condition:
>
> 	if (event->kind == ASCII_KEYSTROKE_EVENT)
>
> So it will not do anything for non-ASCII keystrokes.  You should move
> the code out of that condition, I think.
>
>> +                if (uppercasep(c) &&
>> +                    !(event->modifiers & shift_modifier) )
>
> A nit: our coding standards request a space between the function name
> and the opening parenthesis that follows it, and no spaces between
> closing parentheses.

OK. How about this?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch --]
[-- Type: text/x-diff, Size: 2063 bytes --]

From e3a0375ea66a746a6a02e94f85ef71bf7fe9db5d Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@secretsauce.net>
Date: Sat, 17 Sep 2016 23:47:48 -0700
Subject: [PATCH] Caps-lock doesn't affect interpretation of key chords

* src/keyboard.c (make_lispy_event): when a user pressed key-chords the
caps-lock no longer affects the "shift" state of the generated chord.  For
instance Control+s produces C-s regardless of the caps-lock state.  And
Control+Shift+s produces C-S-s regardless of the caps-lock state.
---
 src/keyboard.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/src/keyboard.c b/src/keyboard.c
index b8bc361..e8a199d 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5417,6 +5417,37 @@ make_lispy_event (struct input_event *event)
 	  {
 	    c &= 0377;
 	    eassert (c == event->code);
+          }
+
+
+        /* Caps-lock shouldn't affect interpretation of key chords:
+           Control+s should produce C-s whether caps-lock is on or
+           not.  And Control+Shift+s should produce C-S-s whether
+           caps-lock is on or not. */
+        if (event->modifiers & ~shift_modifier)
+        {
+            /* this is a key chord: some non-shift modifier is
+               depressed */
+
+            if (uppercasep (c) &&
+                !(event->modifiers & shift_modifier))
+            {
+                /* Got a capital letter without a shift.  The caps
+                   lock is on.   Un-capitalize the letter */
+                c = downcase(c);
+            }
+            else if (lowercasep (c) &&
+                     (event->modifiers & shift_modifier))
+            {
+                /* Got a lower-case letter even though shift is
+                   depressed.  The caps lock is on.  Capitalize the
+                   letter */
+                c = upcase(c);
+            }
+        }
+
+	if (event->kind == ASCII_KEYSTROKE_EVENT)
+	  {
 	    /* Turn ASCII characters into control characters
 	       when proper.  */
 	    if (event->modifiers & ctrl_modifier)
-- 
2.9.3

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: npostavs@users.sourceforge.net, 24456@debbugs.gnu.org
> Date: Sun, 25 Sep 2016 11:44:23 -0700
> 
> > Thanks.  However, this doesn't look right to me: your code is entirely
> > inside the following condition:
> >
> > 	if (event->kind == ASCII_KEYSTROKE_EVENT)
> >
> > So it will not do anything for non-ASCII keystrokes.  You should move
> > the code out of that condition, I think.
> >
> >> +                if (uppercasep(c) &&
> >> +                    !(event->modifiers & shift_modifier) )
> >
> > A nit: our coding standards request a space between the function name
> > and the opening parenthesis that follows it, and no spaces between
> > closing parentheses.
> 
> OK. How about this?

Looks okay, but you still didn't leave a space before the opening
parentheses and the function name.

Did you try this with a non-ASCII key (assuming you have one on your
keyboard)?

Thanks.

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Andreas Schwab]

On Sep 25 2016, Dima Kogan <dima@secretsauce.net> wrote:

> +            if (uppercasep (c) &&

Line break before operator, not after.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Dima Kogan]

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

Andreas Schwab <schwab@linux-m68k.org> writes:

> Line break before operator, not after.

Eli Zaretskii <eliz@gnu.org> writes:

> Looks okay, but you still didn't leave a space before the opening
> parentheses and the function name.

Attached. Is there a tool to automatically detect/fix these?



> Did you try this with a non-ASCII key (assuming you have one on your
> keyboard)?

I did not try. I live in the US, and pretty much never see keyboards
with anything non-trivial on them. If somebody else would test it, that
would be great.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch --]
[-- Type: text/x-diff, Size: 2069 bytes --]

From 9b12fff089dd3a4eb99373e92c635c20cebd0198 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@secretsauce.net>
Date: Sat, 17 Sep 2016 23:47:48 -0700
Subject: [PATCH] Caps-lock doesn't affect interpretation of key chords

* src/keyboard.c (make_lispy_event): when a user pressed key-chords the
caps-lock no longer affects the "shift" state of the generated chord.  For
instance Control+s produces C-s regardless of the caps-lock state.  And
Control+Shift+s produces C-S-s regardless of the caps-lock state.
---
 src/keyboard.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/src/keyboard.c b/src/keyboard.c
index ccd3405..cdeea8e 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5368,6 +5368,37 @@ make_lispy_event (struct input_event *event)
 	  {
 	    c &= 0377;
 	    eassert (c == event->code);
+          }
+
+
+        /* Caps-lock shouldn't affect interpretation of key chords:
+           Control+s should produce C-s whether caps-lock is on or
+           not.  And Control+Shift+s should produce C-S-s whether
+           caps-lock is on or not. */
+        if (event->modifiers & ~shift_modifier)
+        {
+            /* this is a key chord: some non-shift modifier is
+               depressed */
+
+            if (uppercasep (c)
+                && !(event->modifiers & shift_modifier))
+            {
+                /* Got a capital letter without a shift.  The caps
+                   lock is on.   Un-capitalize the letter */
+                c = downcase (c);
+            }
+            else if (lowercasep (c)
+                     && (event->modifiers & shift_modifier))
+            {
+                /* Got a lower-case letter even though shift is
+                   depressed.  The caps lock is on.  Capitalize the
+                   letter */
+                c = upcase (c);
+            }
+        }
+
+	if (event->kind == ASCII_KEYSTROKE_EVENT)
+	  {
 	    /* Turn ASCII characters into control characters
 	       when proper.  */
 	    if (event->modifiers & ctrl_modifier)
-- 
2.8.0.rc3

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: npostavs@users.sourceforge.net, 24456@debbugs.gnu.org
> Date: Sat, 01 Oct 2016 08:12:27 -0700
> 
> > Looks okay, but you still didn't leave a space before the opening
> > parentheses and the function name.
> 
> Attached.

Looks good, thanks.

> Is there a tool to automatically detect/fix these?

I'm not aware of any, but that doesn't mean there isn't one.

> > Did you try this with a non-ASCII key (assuming you have one on your
> > keyboard)?
> 
> I did not try. I live in the US, and pretty much never see keyboards
> with anything non-trivial on them. If somebody else would test it, that
> would be great.

Could someone please try that and see if it works correctly?

bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords

[Eli Zaretskii]

> Date: Sat, 01 Oct 2016 18:59:05 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24456@debbugs.gnu.org, npostavs@users.sourceforge.net
> 
> > From: Dima Kogan <dima@secretsauce.net>
> > Cc: npostavs@users.sourceforge.net, 24456@debbugs.gnu.org
> > Date: Sat, 01 Oct 2016 08:12:27 -0700
> > 
> > > Looks okay, but you still didn't leave a space before the opening
> > > parentheses and the function name.
> > 
> > Attached.
> 
> Looks good, thanks.
> 
> > Is there a tool to automatically detect/fix these?
> 
> I'm not aware of any, but that doesn't mean there isn't one.
> 
> > > Did you try this with a non-ASCII key (assuming you have one on your
> > > keyboard)?
> > 
> > I did not try. I live in the US, and pretty much never see keyboards
> > with anything non-trivial on them. If somebody else would test it, that
> > would be great.
> 
> Could someone please try that and see if it works correctly?

No further comments, so I pushed this to the master branch, and I'm
marking this bug done.

Thanks.