Convert byte offset to char, to fix wrong highlight in non ascii text#95
Convert byte offset to char, to fix wrong highlight in non ascii text#95artur-shaik wants to merge 10 commits into
Conversation
| let e.errorlength = len(strcharpart(line_from, e.fromx, e.errorlength)) | ||
| let e.fromx = byteidx(line_from,str2nr(e.fromx))+1 | ||
| let e.tox = byteidx(line_to,str2nr(e.tox)) | ||
| if ch_from =~ '\(\s\|[`<>!@#$%^&*(){}\[\].,:;\"''\\/]\)' |
There was a problem hiding this comment.
This check looks very ad-hoc.
- What is a purpose of this condition? I could not read the intention
- Please use
=~#since=~behavior depends on user's configuration
There was a problem hiding this comment.
As I said in first message byteidx sometimes return not enough bytes, I couldn't determine why. That's why I used such hacky solution to shift highlight if first character is a symbol or whitespace.
There was a problem hiding this comment.
I'm still not understanding the problem well. Would you help me to understand it by showing some example which requies this hack?
There was a problem hiding this comment.
Here is example result without this conditional shift:
Second match is missed one character. Sometimes byteidx result is not enough for matchaddpos for one byte. That's why I used this hack to find if we are on word's start position.
And here result with shifting:
|
Ok, I finally could make deep dive in this feature. As a result I could remove this hacky condition. |
|
Also, added |
2 participants
This PR contains code for fixing wrong highlight due to that vim works with bytes not chars. Should fix #61.
Must say that
byteidxmethod in vim sometimes return not exact result, so I used some hacks to shift highlight in right position.I did't test it with multyline highlight, because couldn't emulate such grammatic error.
This feature disabled by default, to enable it you need to set
g:grammarous#convert_char_to_byteto1.