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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24456 in the body.
You can then email your comments to 24456 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sun, 18 Sep 2016 00:01:23 -0700

[Message part 1 (text/plain, inline)]

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.

[0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch (text/x-diff, inline)]

From 7e34d122ff981c4a9eb671aa2400efbf65144506 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima <at> 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

Message #8 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sun, 18 Sep 2016 10:04:50 -0400

forcemerge 4931 24456
quit

Dima Kogan <dima <at> 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

Message #13 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sun, 18 Sep 2016 17:41:50 +0300

> From: Dima Kogan <dima <at> 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?

Message #16 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: npostavs <at> users.sourceforge.net
Cc: 24456 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sun, 18 Sep 2016 11:25:46 -0700

[Message part 1 (text/plain, inline)]

npostavs <at> 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

[0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch (text/x-diff, inline)]

From 66510839464f0efdc625790f3e64091012408dda Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima <at> 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

Message #19 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sun, 18 Sep 2016 14:54:13 -0400

Dima Kogan <dima <at> secretsauce.net> writes:

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

Message #22 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Mon, 19 Sep 2016 05:23:53 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 24456 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> 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.

Message #25 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sun, 18 Sep 2016 22:22:09 -0700

Eli Zaretskii <eliz <at> 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?

Message #28 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Mon, 19 Sep 2016 19:43:25 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: npostavs <at> users.sourceforge.net, 24456 <at> 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.

Message #31 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Mon, 19 Sep 2016 11:15:37 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dima Kogan <dima <at> secretsauce.net>
>> Cc: npostavs <at> users.sourceforge.net, 24456 <at> 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-ó.

Message #34 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Mon, 19 Sep 2016 21:50:38 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: npostavs <at> users.sourceforge.net, 24456 <at> 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?

Message #37 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Mon, 19 Sep 2016 13:28:56 -0700

Eli Zaretskii <eliz <at> 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.

Message #40 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Wed, 21 Sep 2016 17:56:51 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: npostavs <at> users.sourceforge.net, 24456 <at> debbugs.gnu.org
> Date: Mon, 19 Sep 2016 13:28:56 -0700
> 
> Eli Zaretskii <eliz <at> 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.

Message #43 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Wed, 21 Sep 2016 16:30:21 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> 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.

[0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch (text/x-diff, inline)]

From 2b81504e1f34fed36c5ec1ee95dbceaf8df9d321 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima <at> 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

Message #46 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Thu, 22 Sep 2016 18:22:55 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: npostavs <at> users.sourceforge.net, 24456 <at> 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.

Message #49 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sun, 25 Sep 2016 11:44:23 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> 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?

[0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch (text/x-diff, inline)]

From e3a0375ea66a746a6a02e94f85ef71bf7fe9db5d Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima <at> 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

Message #52 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sat, 01 Oct 2016 11:28:07 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: npostavs <at> users.sourceforge.net, 24456 <at> 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.

Message #55 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sat, 01 Oct 2016 10:37:17 +0200

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

> +            if (uppercasep (c) &&

Line break before operator, not after.

Andreas.

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

Message #58 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sat, 01 Oct 2016 08:12:27 -0700

[Message part 1 (text/plain, inline)]

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

> Line break before operator, not after.

Eli Zaretskii <eliz <at> 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.

[0001-Caps-lock-doesn-t-affect-interpretation-of-key-chord.patch (text/x-diff, inline)]

From 9b12fff089dd3a4eb99373e92c635c20cebd0198 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima <at> 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

Message #61 received at 24456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sat, 01 Oct 2016 18:59:05 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: npostavs <at> users.sourceforge.net, 24456 <at> 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?

Message #66 received at 24456-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dima <at> secretsauce.net
Cc: 24456-done <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24456: 25.1;
 [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Sat, 15 Oct 2016 17:23:59 +0300

> Date: Sat, 01 Oct 2016 18:59:05 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 24456 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
> 
> > From: Dima Kogan <dima <at> secretsauce.net>
> > Cc: npostavs <at> users.sourceforge.net, 24456 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.