[Vim-latex-devel] [ vim-latex-Patches-3057689 ] IMAP with mulitbyte lhs

[SourceForge.net <no...@so...>]

Patches item #3057689, was opened at 2010-09-01 12:23
Message generated for change (Comment added) made by lux-vim-latex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3057689&group_id=52322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: LuX (lux-vim-latex)
Assigned to: Nobody/Anonymous (nobody)
Summary: IMAP with mulitbyte lhs

Initial Comment:
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. 

----------------------------------------------------------------------

>Comment By: LuX (lux-vim-latex)
Date: 2012-05-25 16:54

Message:
*Bump*

----------------------------------------------------------------------

Comment By: LuX (lux-vim-latex)
Date: 2010-11-14 13:40

Message:
> 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. 

----------------------------------------------------------------------

Comment By: Till Maas (tmaas)
Date: 2010-10-28 13:37

Message:
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)

----------------------------------------------------------------------

Comment By: LuX (lux-vim-latex)
Date: 2010-09-06 10:53

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3057689&group_id=52322