Random US-International keyboard layout (dead keys) support

[GoogleCodeExporter]

What steps will reproduce the problem?
1. OS: Win7 64 (32bit GVIm build)
2. Use US-International keyboard layout
3. In insert mode try to insert ' " ` ~ (hit the corresponding key followed by 
<SPACE>)

What is the expected output? What do you see instead?

Vim will fail to insert those characters on a fairly random basis.

The issue is perfectly described there: 
http://stackoverflow.com/questions/3937237/gvim-us-international-not-combining-d
ead-keys-with-space
and there:
http://vim.1045645.n5.nabble.com/dead-key-bug-td4358973.html

What version of the product are you using? On what operating system?
7.4.402 on Win7x64

Please provide any additional information below.

The issue seems random but dependent on the compiler and optimisations used, it 
first appeared with vim7. For years I have been dodging this issue by using 
@wuyongwei builds but his latest 7.4.402 unfortunately exhibits the problem.

Original issue reported on code.google.com by John.Wel...@gmail.com on 19 Aug 2014 at 12:09

[GoogleCodeExporter]

This has been reported before:
https://groups.google.com/d/msg/vim_dev/99DYFZvvBNE/xuwuWsZdc1IJ
sounded like a compiler bug to me. Unfortunately now patch has been offered to 
fix this issue.

Original comment by chrisbr...@googlemail.com on 19 Aug 2014 at 7:14

[GoogleCodeExporter]

In the past I remember testing several builds and if I remember correctly some 
of the 'VIm without cream' builds did also exhibits this problem and thus I 
settled on Wu Yongwei's.

Now the situation is 'reversed' as the 'VIm without cream' 402 is the one 
working correctly.
on the Stackoverflow link I provided a commenter said that Yongwei's build did 
not solve the problem for him...

I'm not familiar with VIm sources so I don't know where to look for ambiguous 
code (this problem looks like a missing 'sequence point' where depending on the 
circumstances a part of the code would be compiled/executed in a different 
order) 

Original comment by John.Wel...@gmail.com on 19 Aug 2014 at 11:18

[GoogleCodeExporter]

Ok, I've made an interesting discovery that proves that it's not related to 
Microsoft compiler as implied in 
https://groups.google.com/d/msg/vim_dev/99DYFZvvBNE/xuwuWsZdc1IJ

I've managed to compile two versions of gvim using mingw64 one for i686 and the 
other for x86-64 (both with directx):

the i686 32it version doesn't have the issue discussed here while the x64 build 
does!

So I have a build environment where I can easily reproduce the problem, any 
idea where to look in the sources for dead key handling?

Original comment by John.Wel...@gmail.com on 20 Aug 2014 at 2:41

[GoogleCodeExporter]

Can you try, if building without optimiziations fixes your issue as well?

Original comment by chrisbr...@googlemail.com on 20 Aug 2014 at 7:02

[GoogleCodeExporter]

I've found and fixed the problem. Here is a patch.

A custom MSG structure used for sending a fake VK_SPACE was declared locally 
before being used with TranslateMessage().

Solution: declare the MSG struct statically instead.

Original comment by John.Wel...@gmail.com on 20 Aug 2014 at 9:06

Attachments:

• 0001-Fix-possible-undefined-behavior-when-handling-non-al.patch

[GoogleCodeExporter]

Looks like a solution. Increases Vim's size by SIZEOF(MSG) again, though :-)

Original comment by christ.v...@coosto.com on 20 Aug 2014 at 9:20

[GoogleCodeExporter]

I came up with a much nicer solution that actually addresses the underlying 
issue and that decreases Vim's size^^

Besides this bug, dead key handling was not behaving like in other Windows 
application.

I spent some time understanding 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646267(v=vs.85).aspx#_
win32_Dead_Character_Messages

So the solution is to reset dead_key as soon as any WM_CHAR is received and to 
_NOT_ do anything special if dead_key is set and the key being pressed is 
either VK_SPACE, VK_BACK or VK_ESCAPE in which case we just let WIndows 
generate its WM_CHAR: just one will be generated if it's VK_SPACE being pressed 
or two will be if it's either VK_BACK or VK_ESCPAE (the dead key + the VK_BACK 
or VK_ESCPAE)

My patch includes a detailed comment on the logic used

The fix is very simple and feels just right :)

Original comment by John.Wel...@gmail.com on 20 Aug 2014 at 7:06

Attachments:

• 0001-Fix-dead-key-handling-on-Windows-non-standard-behavi.patch

[GoogleCodeExporter]

Included as patch 7.4.413

Original comment by brammool...@gmail.com on 22 Aug 2014 at 4:45

• Changed state: Fixed