GNU bug report logs - #44641
[PATCH] Ignore modifiers when processing WM_IME_CHAR messages

Previous Next

Package: emacs;

Reported by: tsuucat <tsuucat <at> icloud.com>

Date: Sat, 14 Nov 2020 16:59:01 UTC

Severity: normal

Tags: patch

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: tsuucat <tsuucat <at> icloud.com>
Subject: bug#44641: closed (Re: bug#44641: [PATCH] Ignore modifiers when
 processing WM_IME_CHAR messages)
Date: Sat, 21 Nov 2020 08:19:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#44641: [PATCH] Ignore modifiers when processing WM_IME_CHAR messages

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 44641 <at> debbugs.gnu.org.

-- 
44641: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44641
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Eli Zaretskii <eliz <at> gnu.org>
To: tsuucat <tsuucat <at> icloud.com>
Cc: 44641-done <at> debbugs.gnu.org
Subject: Re: bug#44641: [PATCH] Ignore modifiers when processing WM_IME_CHAR
 messages
Date: Sat, 21 Nov 2020 10:18:36 +0200
> From: tsuucat <tsuucat <at> icloud.com>
> Date: Mon, 16 Nov 2020 12:07:26 +0900
> Cc: 44641 <at> debbugs.gnu.org
> 
> 
> >> Current Emacs for Windows recognizes modifier keys even when inputting
> >> with IME. Some IMEs use modifier keys to input characters, so this
> >> causes inconvenient for such IME users.
> > 
> > You say "some IMEs", so I wonder whether ignoring modifier keys for
> > WM_IME_CHAR is always the right thing.  Do you know for sure? is that
> > documented somewhere?  (I'm not an expert on MS-Windows IMEs.)
> 
> I believe this change will not affect other IME users. Other IME users
> simply don't use modifier keys to input multibyte characters. For
> example, Chinese IME users type Space to select and input the
> candidate, but typing Ctrl+Space doesn't mean users select and input
> the candidate (= WM_IME_CHAR messages will not happen). 
> 
> Some Japanese IME users type Ctrl+m or Ctrl+n to select and input the
> candidate and they want to send Ctrl to IME not to Emacs.
> 
> I don't have just the right documentation but this change just follows
> the way X build Emacs does. 

OK, thanks.  I installed your changes on the emacs-27 branch, but I
also added a variable, w32-ignore-modifiers-on-IME-input, that allows
to get back the old behavior, in case the new behavior adversely
effects some use cases.

With that, I'm closing this bug report.

[Message part 3 (message/rfc822, inline)]
From: tsuucat <tsuucat <at> icloud.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Ignore modifiers when processing WM_IME_CHAR messages
Date: Sun, 15 Nov 2020 01:58:34 +0900
[Message part 4 (text/plain, inline)]
Current Emacs for Windows recognizes modifier keys even when inputting
with IME. Some IMEs use modifier keys to input characters, so this
causes inconvenient for such IME users.

Example: Microsoft IME (Japanese input method)
If I type Ctrl+m to input こんにちは, I get C-こ C-ん C-に C-ち C-は
in Emacs.

This patch ignores modifier keys when processing WM_IME_CHAR
messages. This patch is not intended to introduce Windows specific
behavior; X build already ignores modifier keys when processing inputs
via XIM.

src/xterm.c:
...
              nbytes = XmbLookupString (FRAME_XIC (f),
                                        &xkey, (char *) copy_bufptr,
                                        copy_bufsiz, &keysym,
                                        &status_return);
...
              else if (status_return == XLookupChars)
                {
                  keysym = NoSymbol;
                  modifiers = 0;
                }
...

--
tsuucat

[0001-Ignore-modifiers-when-processing-WM_IME_CHAR-message.patch (application/octet-stream, attachment)]
[Message part 6 (text/plain, inline)]
 

This bug report was last modified 4 years and 242 days ago.

Previous Next


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