Hi, Ben. > Mmm. I guess it's something to do with the US International keyboard > layout, and Vim not quite understanding it.
I believe so. > A workaround might be to use a keymap, but also switch to a standard US > English keyboard layout (which has no dead keys). All the dead key > handling would be done by Vim then. If Windows switches layouts nicely > as you switch applications and/or remembers the layout is different for > Vim, this could perhaps work quite nicely. I will try this suggestion and give you a feedback. The part that I don't understand in the GVim implementation is why, when I switched off the 'iminsert' option, it doesn't got back to behave just like in versions before 7? I know that is not so simple. I though in terms of handling or not the WM_DEADCHAR Windows message. For example, I haven't this problem when typing an EX command in the command window, because the IM isn't used in there. So, all 'dead-key+key' combination is done in the Operating System level and everything works fine. > Another thing to check is that your Vim is compiled with > +multi_byte_ime. With that and iminsert=2 things should theoretically > play nicely with input methods. Yes, it has '+multi_byte_ime', but 'theoretically' does not became practical every time. =-) > Have a look around the website and you'll see how to get the Vim > sources. It's worth getting recent sources from version control, or > applying the patches to a tarball to bring it up to a fairly recent > version, IMHO. > > Compilation instructions are there too, or in the sources--I can't > really remember, but I don't think they're hard to find. Compiling Vim > is pretty straightforward. Just make sure you choose something like > 'huge' features so you don't get a small Vim which might not have full > multibyte/IME support, etc.. > > I guess you should use the debugger that matches your build environment, > so if you use the MS toolset, use the MS debugger, but if you use MinGW > toolset with gcc, use gdb. I have both. I will try GCC first because it seams more natural to me. > This bug is probably win32-related, and quite probably even win32-GUI > related, so I suggest the gui_w32.c and os_win32.c are the first places > to fish around, and other similarly named files. Vim doesn't have all > that many source files, so it's not too hard to find which file to look > in--harder is finding the right part of the files, which are often > pretty huge. Thanks for the useful tips. I will look at these two files first. Regards, Alessandro -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
