all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dima Kogan <dima@secretsauce.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 24456@debbugs.gnu.org, npostavs@users.sourceforge.net
Subject: bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords
Date: Wed, 21 Sep 2016 16:30:21 -0700	[thread overview]
Message-ID: <8737ks7rw2.fsf@secretsauce.net> (raw)
In-Reply-To: <83mvj1fgi4.fsf@gnu.org>

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


  reply	other threads:[~2016-09-21 23:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-18  7:01 bug#24456: 25.1; [PATCH] Caps-lock doesn't affect interpretation of key chords Dima Kogan
2016-09-18 14:04 ` npostavs
2016-09-18 18:25   ` Dima Kogan
2016-09-18 18:54     ` npostavs
2016-09-19  2:23     ` Eli Zaretskii
2016-09-19  5:22       ` Dima Kogan
2016-09-19 16:43         ` Eli Zaretskii
2016-09-19 18:15           ` Dima Kogan
2016-09-19 18:50             ` Eli Zaretskii
2016-09-19 20:28               ` Dima Kogan
2016-09-21 14:56                 ` Eli Zaretskii
2016-09-21 23:30                   ` Dima Kogan [this message]
2016-09-22 15:22                     ` Eli Zaretskii
2016-09-25 18:44                       ` Dima Kogan
2016-10-01  8:28                         ` Eli Zaretskii
2016-10-01 15:12                           ` Dima Kogan
2016-10-01 15:59                             ` Eli Zaretskii
2016-10-15 14:23                               ` Eli Zaretskii
2016-10-01  8:37                         ` Andreas Schwab
2016-09-18 14:41 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8737ks7rw2.fsf@secretsauce.net \
    --to=dima@secretsauce.net \
    --cc=24456@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=npostavs@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.