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

Previous Next

Full log

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.

Previous Next

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