Patches item #3057689, was opened at 2010-09-01 21: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: 2010-09-06 19: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
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Vim-latex-devel mailing list
Vim-latex-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vim-latex-devel
