multibyte bug with display bounds computation

[emmanueltouzery]

Hello, well the title is my guess as to what is the reason of the issue.
I was trying to track down why lightspeed wouldn't detect characters that I wanted to jump to.

My conclusion is that the get-horizontal-bounds miscomputes the bounds (I believe) when there are multibyte characters at play. So my theory is that if you have 32 characters and 35 bytes, it'll return bounds of 1-32. But I think other functions count in bytes.
I'm not 100% sure but I believe it's something like that.
And if you have a narrow window, lightspeed will consider a match "out of screen" when it's not.

And I have a reproduction...
If you make a narrow window (let's say 32 characters), then you put like 30 multibyte characters and then for instance a f. Then insert a newline and press Sf to try to jump to the f -- lightspeed won't offer the jump. If you make the window wider (for instance 100 characters), or if you replace the multibyte characters with spaces.. everything will work as expected.

I could reproduce for instance with this text:
经经经经经经经经经经经f

I even split in two windows displaying that text, a narrow one and a wide one -- lightspeed could jump correctly in the wide one, and not in the narrow one.

[emmanueltouzery]

How I stumbled in that issue.. I wanted to use lightspeed to jump in nvim-tree windows. nvim-tree windows are narrow, and they contain multibyte characters: nerdfont icons for file type, git status and so on.

[emmanueltouzery]

as a workaround for my use-case I've changed in the generated lua the return value of get_horizontal_bounds like so:

-  return {left_bound, right_bound}
+  return {left_bound, right_bound+5}

And that helps with my issues.