Christian Brabandt wrote: > > > Bram, > > > There are still two open issues with langmaps. One is issue 297 > > > (https://code.google.com/p/vim/issues/detail?id=297), the other one is > > > this one > > > (https://groups.google.com/d/msg/vim_dev/5D1WSL2gj-A/OgCBNZQEHNEJ) > > > > > > I have checked the problem and I think the problem is, that mappings > > > won't be resolved after a multibyte characters have been read. This is > > > caused, by the fact that vgetorpeek() that resolves mappings, doesn't > > > know about multibyte chars, since those are only known in the higher > > > level vgetc() function. But after applying the langmap there, Vim > > > won't check, if the input needs to be resolved for mappings. > > > > > > Therefore I changed vgetc() function to resolve langmaps after the > > > multibyte chars have been read correctly and once this changed the > > > input character and a mapping for that character exists, put that > > > character again into the typeahead buffer and run vgetorpeek() again. > > > > > > Attached patch includes 2 tests, that are taken from the above issues > > > and demonstrate the problem. > > > > I think this is not right. LANGMAP_ADJUST() is already called inside > > vgetorpeek(). After your change it would also be called on the result. > > Isn't that, what is happening currently anyhow? LANGMAP_ADJUST() is > called inside vgetorpeek() and again in normal.c after safe_vgetc()
Hmm, it's slightly differently. Inside vgetorpeek() LANGMAP_ADJUST() is only used to check for a matching mapping. It's not used to actually change the returned character. The LANGMAP_ADJUST() in normal.c does the actual translation. So the problem in vgetorpeek() is that LANGMAP_ADJUST() is only applied to a byte, not a character. Your change to call LANGMAP_ADJUST() in vgetc() does cause a double translation. That can be avoided by returning the original character, but it doesn't handle multi-character mappings. I don't think there is a simple solution, would need to apply LANGMAP_ADJUST() in vgetorpeek() on every character before checking for a mapping, but not actually returning the adjusted character when no mapping matches. > > I think the right solution is to change the code around LANGMAP_ADJUST() > > inside vgetorpeek(). It needs to check for the lead byte of a > > multi-byte character and get the whole multi-byte character out of > > typebuf. There are two such places. The tricky part is checking for a > > mappping, because the byte length of a character may change after > > applying LANGMAP_ADJUST(). > > Hm, have to check this again. -- % cat /usr/include/life.h void life(void); /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
