#5 IMAP with mulitbyte lhs

Unstable (example)
closed-fixed
nobody
None
5
2014-11-15
2010-09-01
LuX
No

The IMAP function, which comes with the latex-suite in the plugin imaps.vim, deals wrongly with multibyte left hand side (so-called lhs). The attached patch fixes this.

Version number:
imaps.vim 997 2006-03-20 09:45:45Z srinathava $
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Dec 1 2008)

Example:
You want to chain IMAP mapping, as follows:
call IMAP("\\subset", "⊂", "")
call IMAP("⊂eq", "⊆", "")
Type "1234\subset", you see "1234⊂" (good). But if you add "eq", you see "12⊆" (bad) instead of "1234⊆".

Description:
The attached patch adds to imaps.vim two functions called s:MultiByteStrlen and s:MultiByteStrpart, analogous to Vim's functions strlen and strpart but which deal with strings character per character instead of byte per byte. Every call to strlen and strpart is then replaced by a call to these variants, and as far as I can see it solved the problem.

Discussion

  • LuX
    LuX
    2010-09-06

    Sorry, it appeared to me that the previously attached patch was not correct (I did not apply 'diff' to the right files). But most of all the strategy of changing every call to strlen and strpart by my s:MultiByte* variants is not good: in some case, it is really strpart or strlen which must be used.

    Example:
    The following command appears 3 times in imaps.vim:
    strpart(getline(".", 0, col(".")-1)
    What is expected is the content of the current line before the cursor. Since col(".") returns the number of bytes, not of characters, until the first byte (not the last one) of the character under the cursor, col(".")-1 is just the number of bytes in the current line before the cursor. Thus strpart will return what expected, and MultiByteStrpart will not (not always).

    So this time I have looked carefully at every place in imps.vim where strlen and strpart were used, and I changed them to there s:MuliByte-variants ONLY when I was sure that it was needed (I left strlen and strpart also when it did not make any difference to use them or s:MultiByte*, for example when they are called only to test wether or not a string is empty).

    The result of this better strategy is the attached patch.

     
  • LuX
    LuX
    2010-09-06

    Allows multibyte lhs in IMAP (revised patch: 2nd version)

     
    Attachments
  • Till Maas
    Till Maas
    2010-10-28

    This change looks wrong:
    @@ -194,7 +194,7 @@
    "
    " Added mainly for debugging purposes, but maybe worth keeping.
    function! IMAP_list(lhs)
    - let char = a:lhs[strlen(a:lhs)-1]
    + let lastLHSChar = s:MultiByteStrpart(a:lhs,s:MultiByteStrlen(a:lhs)-1)
    let charHash = s:Hash(char)
    if exists("s:LHS_" . &ft ."_". charHash) && a:lhs =~ s:LHS_{&ft}_{charHash}
    let ft = &ft

    Are you sure this is correct? I guess the new line needs to be:
    + let char = s:MultiByteStrpart(a:lhs,s:MultiByteStrlen(a:lhs)-1)

     
  • LuX
    LuX
    2010-11-14

    > tmaas wrote:
    > This change looks wrong:
    > @@ -194,7 +194,7 @@
    [..]
    > Are you sure this is correct? I guess the new line needs to be:
    > + let char = s:MultiByteStrpart(a:lhs,s:MultiByteStrlen(a:lhs)-1)

    Yes, you're right, of course. Sorry about that.

     
  • LuX
    LuX
    2010-11-14

    Allows multibyte lhs in IMAP (revised patch: version 3)

     
    Attachments
  • LuX
    LuX
    2012-05-25

    *Bump*

     
  • LuX
    LuX
    2013-07-23

    Hello!
    I haven't received any news about this patch since I fixed the last error pointed by tmaas. It was almost 3 years ago (revised patch: version 3, 2010-11-14). Why is it still waiting?
    Regards.

     
  • Till Maas
    Till Maas
    2014-11-15

    merged in 02cce0426380131fa0067a7fbf64f2dd14d86111, thank you for your patience.

     
  • Till Maas
    Till Maas
    2014-11-15

    • status: open --> closed-fixed
    • Group: --> Unstable (example)