Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert byte offset to char, to fix wrong highlight in non ascii text #95

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

artur-shaik
Copy link

This PR contains code for fixing wrong highlight due to that vim works with bytes not chars. Should fix #61.

Must say that byteidx method 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_byte to 1.

autoload/grammarous.vim Outdated Show resolved Hide resolved
autoload/grammarous.vim Show resolved Hide resolved
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\|[`<>!@#$%^&*(){}\[\].,:;\"''\\/]\)'
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Owner

@rhysd rhysd Dec 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not understanding the problem well. Would you help me to understand it by showing some example which requies this hack?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is example result without this conditional shift:

2020-12-14-113438_863x345_scrot

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:
2020-12-14-113957_895x347_scrot

@artur-shaik artur-shaik requested a review from rhysd December 1, 2020 08:34
@artur-shaik
Copy link
Author

artur-shaik commented Mar 3, 2021

Ok, I finally could make deep dive in this feature. As a result I could remove this hacky condition.

@artur-shaik
Copy link
Author

artur-shaik commented Mar 29, 2021

Also, added --line-by-line argument to LanguageTool. This fix LT response, when fromx position is in wrong place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong highlight in Russian language
2 participants