Christian Brabandt wrote: > Hi Bram! > > On Di, 09 Jun 2015, Bram Moolenaar wrote: > > > 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. > > It's tricky, as one can't call vgetorpeek() recursively to receive the > next characters. Here is a patch, that seems to work and that does not > seem to brake the other tests. So that is good. > > However, I don't know, from where to get characters from. I am not sure, > if one needs to check the stuffbuf or other buffers to check for another > char. Currently, this gets characters from the user and from the > scriptfile (that I discovered from the non-working test ;)) > > I would appreciate some feedback especially if I need to get characters > from other places as well or if there needs to be checked some more.
It looks like this would work. The whole typeahead handling is getting more and more complicated. I have been wondering if the whole typebuf could be refactored. It's tricky because when getting the next character one may be in Insert mode, and the next call it may be in Normal mode, thus different mappings and langmap apply. One can't just change the buffer to apply langmap before matching with a mapping. For some things it may help to make it a list of characters instead of bytes. However, mappings may work on bytes, not characters. -- I AM THANKFUL... ...for a lawn that needs mowing, windows that need cleaning and gutters that need fixing because it means I have a home. /// 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.
