GNU bug report logs -
#44641
[PATCH] Ignore modifiers when processing WM_IME_CHAR messages
Previous Next
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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44641 in the body.
You can then email your comments to 44641 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44641
; Package
emacs
.
(Sat, 14 Nov 2020 16:59:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
tsuucat <tsuucat <at> icloud.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 14 Nov 2020 16:59:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (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 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44641
; Package
emacs
.
(Sat, 14 Nov 2020 17:26:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44641 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 15 Nov 2020 01:58:34 +0900
> From: tsuucat via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> 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.)
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44641
; Package
emacs
.
(Mon, 16 Nov 2020 03:08:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 44641 <at> debbugs.gnu.org (full text, mbox):
>> 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.
--
tsuucat
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 21 Nov 2020 08:19:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
tsuucat <tsuucat <at> icloud.com>
:
bug acknowledged by developer.
(Sat, 21 Nov 2020 08:19:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 44641-done <at> debbugs.gnu.org (full text, mbox):
> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 19 Dec 2020 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 241 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.