Feature/Color-highlight improvements

[akinsho]

Update the color highlight's fontfamily if a user changes their font mid session currently the font is set in the constructor and doesn't update if the the users font family changes , update the regex to match only on words i.e not mid string

Add a background to cover the underlying text so the color doesnt bleed through

This PR doesn't address the regex issue as it is seemingly more complicated to resolve than I imagined for example white-space currently gets matched because of the white the issue with this is that the regex fuzzy matches so that for example a react component like <Component color={"white"} /> gets matched i.e. the quotes wouldnt stop the match or :black the colon wouldn't stop the match, I'm not sure just stopping the hyphen specifically would be enough as html entities can also match so its not entirely clear what the right boundaries should be. Looking at vscode highlight plugins they seem to employ a range of different regexes depending on the filetype so support is only for some filetypes that there is a strategy for. Our current solution is far more general but causes these edge cases 🤔

Outstanding:

• mid color input rarely the editor can crash whilst an incomplete rgba color was being input, somehow the incomplete color was passed to the styled component causing it throw an error -> prevent incomplete match, seems rare as its is not easily reproduc

[codecov]

Codecov Report

Merging #2447 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2447   +/-   ##
=======================================
  Coverage   42.62%   42.62%           
=======================================
  Files         332      332           
  Lines       13212    13212           
  Branches     1736     1736           
=======================================
  Hits         5632     5632           
  Misses       7302     7302           
  Partials      278      278

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4ce7b50...598a7e5. Read the comment docs.

[CrossR]

I'm getting a slight misalignment on my end with this, so the cursor can start covering the next char along, as well as not being aligned at the top/bottom.

It's possibly something to do with scaling on my machine?
This was in the onedark.vim file, but also happened in the onedark.json file.
It might be anecdotal...but I felt like it was becoming more misaligned the further down the string I went.

[akinsho]

@CrossR thanks for testing it locally tbh that issue has been there since the initial implementation, the problem as far as I can tell is that the cursor is rendered a little lower down on the line than expected not sure how or why exactly and as for the text it seems to render slightly differently in the html element than in the webgl renderer so is mismatched.

I position the element over the renderer and found that the positions I get fromt the layer context dont quite match up exactly, tbh I have no idea re. a quick solution to that except for possibly disabling the highlights on the current line which is actually a feature I saw a vscode highlight plugin I was looking at just added

EDIT: its is less pronounced on my machine re the fonts overlapping so could very well be how the renderer scales text I'm not sure though

[CrossR]

Assuming @bryphe is okay with it, seems like its more an issue of the buffer layer and how it is aligned, rather than your colour highlight layer? So its probably worth fixing that in a separate PR since I expect it'll come up again if we do whitespace etc.

[akinsho]

Yeah I think there are few things which need to be updated re. the layer rendering in general like pixel positions and visible lines that adapt to wrapping and folding, inputting lines programmatically as well as slight differences in positioning

although I think the last of those will be the hardest, that being said the cursor seems able to account for the way things are positioned so there might be some tweaks we need to replicate for renderer elements but in general positions are reliable as long as were not dealing with tiny mismatches so think white space would actually be fine

I plan on (when/if I figure out solutions) making a series of small prs for stuff like that as well as ongoing tweaks since both this and the indent lines still have issues to be resolved

[akinsho]

@CrossR do you want to wait for @bryphe (because its otherwise done on my end) on this PR as it currently just tackles one of a few different issues with this layer I'd ideally like to keep this PR scoped to the background bleeding issue and the crash which I noted which this fixes although there are definitely still some outstanding fixes I need to add (in other PRs).

[CrossR]

Think its fine to merge now, as you've said this PR doesn't add any new issues, and its a fix needed somewhere else entirely in the code.

May be worth raising an issue about the alignment issues so we have it logged somewhere though.

[akinsho]

@CrossR thanks for the approval I'll add the alignment issues to the project board for the layers re. solution I'm actually thinking of just not rendering the highlight for the current cursor line since it's the most straight forward fix and not sure how desirable/necessary it is to have the highlight on the current line