mirror of
https://github.com/rivo/tview.git
synced 2026-04-26 21:35:54 +03:00
[GH-ISSUE #467] Rewrite of the text rendering engine? #334
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tview#334
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gnojus on GitHub (Jul 9, 2020).
Original GitHub issue: https://github.com/rivo/tview/issues/467
Hi.
As I'm further delving into and modifying
tview, I came to realize that the current implementation of text parsing and rendering is quite complex, difficult to understand and maybe could be improved? A lot of parsing, clustering and regexing is happening at draw time. Maybe it could parsed better for easier rendering later?Anyway, if you are open to this, I'm up to implement that if we find a way how. Or maybe it's fine the way it is, I'm not sure.
@rivo commented on GitHub (Jul 12, 2020):
I'm simplifying as I go along. This engine has probably been rewritten three or four times already. The biggest driver of these changes was proper Unicode support. I have to admit that when I started
tview, I didn't know much about Unicode code points. And as it turns out,tcell(on whichtviewis based) didn't handle them properly, either. It continues even with themattn/go-runewidthpackage which doesn't handle Unicode properly. And you can't ignore that topic because there will always be someone who lets me know that some emoji or maybe some Asian character is not rendered properly.I even had to write the
rivo/unisegpackage to deal properly with splitting text into its individual characters. This further simplified the code. And I expect that when correct word-splitting (rivo/uniseg#2) is implemented inrivo/uniseg, there will be further simplifications.Sure, we could write an actual parser for text and get rid of the regexes. But at this point, I'm not so sure if this would actually reduce complexity that much.
As a side note, I would advise against writing code now and submitting it to me. PR's are piling up because I don't have time to look into all the code that has been submitted. And I expect that this one would be a huge PR. (Larger PR's are possible if we work together on them from the very beginning like I did with @millerlogic on #363. But there has to be an urgent need. I'm not sure this is the case here.)
@gnojus commented on GitHub (Jul 12, 2020):
All right, I see your reasons. Anyway, despite your advise I did write parser and iterator, for myself at least. The parser still uses regexes and is not that different, but when parsed, in my opinion, it's more pleasant to iterate and I finally understand what's happening.
I understand about PR's too, as my own quick 3-liner fix is lying there for a few months. There is no point to pile up the PR's even more, especially if you don't find this necessary. In any case, if you would actually consider this later, let me know and maybe we can work something out.
@rivo commented on GitHub (Jan 11, 2021):
What's the number of the 3-liner fix?
@gnojus commented on GitHub (Jan 13, 2021):
#410
@rivo commented on GitHub (Aug 26, 2023):
The
TextViewand all other text rendering functions have been completely rewritten. I will therefore close this issue. If there's anything wrong with the new code, please open a new issue.