Disable Alt+` on Windows

[niwazukihon]

Hi, I'd like to disable the Alt+` hotkey to switch between hiragana and direct input on Windows, because I want to use that hotkey for other things. It's not in the keymap settings. I found #395 and saw the quoted code. I deleted the code

 {kTipPreservedKey_Kanji,
     {VK_OEM_3, TF_MOD_ALT},
     VK_OEM_3,
     &kTipKeyTilde[0],
     std::size(kTipKeyTilde) - 1},

from src/win32/tip/tip_text_service.cc, but it doesn't work.

[yukawa]

OK, on my Windows 11 24H2 environment, the behavior observed from the IME (e.g. Mozc) has changed from what I described in #395.

As of Windows 11 24H2, I think you can achieve your goal as follows.

1. Open Mozc property. (e.g. right click the Mozc mode icon on the task bar then select "Property")
2. Click "Customize" in the "keymap style section"
   
3. Remove all the 4 entries associated with "Hankaku/Zenkaku"
   

[yukawa]

Note that here are what I can observe in my local environment.

1. Open a notepad app.
2. Down Alt key.
3. Down ` key. Mozc receives VK_DBE_DBCSCHAR down.
4. Up ` key. Mozc receives VK_KANJI up.
5. Down ` key. Mozc receives VK_DBE_DBCSCHAR down.
6. Up ` key. Mozc receives VK_KANJI up.
7. Up Alt key.

As you can see, what Mozc is receiving are VK_DBE_DBCSCHAR and VK_KANJI. Such a conversion is done at the OS layer.

In this scenario, Mozc basically ignores key up events so let's ignore VK_KANJI at the step 4 and step 6.
When Mozc receives VK_DBE_DBCSCHAR, it will be internally interpreted as "Hankaku/Zenkaku" as follows.

mozc/src/win32/base/keyevent_handler.cc

Line 316 in 4c7f048

KeyEvent::HANKAKU, // 0xF4: VK_DBE_DBCSCHAR

This is why you need to modify the key bindings associated with "Hankaku/Zenkaku".

[niwazukihon]

Thank you for the reply. I removed the 4 entries, but the hotkey I mapped in autohotkey still doesn't work when mozc is activated. But from your comment, I guess you meant that the OS gives a special treatment of alt+` when using Japanese keyboard, and when I removed all 4 entries, essentially mozc doesn't do anything with what comes out of the OS.

Then, by looking into the ahk key history, I found that it seems ahk is receiving vk19 (VK_KANJI) (and vkE8). Holding it down keeps sending vk19. I don't see vkF4. So, I tried this script

<!`:: Home
<!vk19:: Home

And it works. In fact, it even works without removing those 4 entries.

[yukawa]

Then, by looking into the ahk key history, I found that it seems ahk is receiving vk19 (VK_KANJI) (and vkE8). Holding it down keeps sending vk19. I don't see vkF4.

Ah, you are right. I've also confirmed that VK_KANJI is received not only for key up but also for key down.

The reason why I thought VK_DBE_DBCSCHAR was sent was because of the following special mapping rule.

mozc/src/win32/tip/tip_text_service.cc

Lines 334 to 342 in b7faa84

	{kTipPreservedKey_Kanji,
	{VK_KANJI, TF_MOD_IGNORE_ALL_MODIFIER},
	// KeyEventHandler maps VK_KANJI to KeyEvent::NO_SPECIALKEY instead of
	// KeyEvent::KANJI because of an anomaly of IMM32 behavior. So, in TSF
	// mode, we treat VK_KANJI as if it was VK_DBE_DBCSCHAR. See b/7592743 and
	// b/7970379 about what happened.
	VK_DBE_DBCSCHAR,
	&kTipKeyKanji[0],
	std::size(kTipKeyKanji) - 1},

So the system was indeed sending VK_KANJI, but the above rule defined in tip_text_service.cc further remapped it to VK_DBE_DBCSCHAR.