#5 IMAP with mulitbyte lhs

[LuX]

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.

[LuX]

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]

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

[Till Maas]

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]

> 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]

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

[LuX]

*Bump*

[LuX]

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]

merged in 02cce0426380131fa0067a7fbf64f2dd14d86111, thank you for your patience.