Unwanted artifacts on screen when scrolling text with a lot of unicode characters
While dealing with text that has a lot of unicode, the characters end up "stuck" on the screen, and in the case of the table, the selector malfunctions. Please take a look at the video.
@rivo @tslocum, I'm really sorry for tagging, but I believe this issue to be critical. Any advise would be much appreciated.
https://user-images.githubusercontent.com/44058754/150971461-9a763188-14b6-4552-a328-c5d94dd08e15.mp4
An update on this issue: The bug occurs on this line (util.go)
screen.SetContent(finalX+offset, y, main, comb, finalStyle)
Writing certain combined runes (?) to the output can cause the entire UI to break, with text being rendered incorrectly and so on.
Setting comb to nil temporarily solves this issue. I can provide another video to show this issue if you'd like.
Please share the text that causes this breakage as well as the application code responsible for displaying it.
@tslocum apologies for the delay.
The application code is simple enough, it can be anything that displays/handles text like a Table/TableCell, InputField, TextView, etc.
package main
import "github.com/rivo/tview"
func main() {
App := tview.NewApplication()
Input := tview.NewInputField()
Input.SetLabel("Edit this: ")
Input.SetText("🔥🔥🔥 में f कैसे लगाएं??जाने बहुत ही खास Colour")
if err := App.SetRoot(Input, true).SetFocus(Input).Run(); err != nil {
panic(err)
}
}
You should notice certain characters "sticking" inside the inputfield.
(Weirdly, some editors like vim and micro also have problems with rendering combined runes. Micro handles unicode in a somewhat similar manner to tview, and the same thing occurs while editing text in micro - the entire UI breaks)
Seems to be related to some issues in other packages. I've opened up issue gdamore/tcell#515.
Also mattn/go-runewidth#59.
I made a suggestion over at go-runewidth, see https://github.com/mattn/go-runewidth/issues/59#issuecomment-1242923961, and also submitted a PR (https://github.com/mattn/go-runewidth/pull/63). When this PR gets accepted, your problem should be solved, at least after this change propagates via tcell (@gdamore) to tview.
I don't know how fast @mattn is with this. We'll see.
Is this issue still relevant? I believe Unicode should work properly now. If there is no further comment soon, I will close this issue.