summaryrefslogtreecommitdiff
path: root/src/terminal/hyperlink.zig
AgeCommit message (Collapse)Author
2025-08-18PageList: increase capacity for hyperlink OOM during reflowQwerasd
It's possible for the hyperlink or string capacity to be exceeded in a single row, in which case it doesn't matter if we move the row to a new page, it will still be a problem. This was causing actual crashes under some circumstances.
2025-02-10fix(terminal): properly lookup hyperlinks when cloning rows across pagesQwerasd
Before this we were doing bad things with the memory, looking at `PageEntry`s for links not actually in the page we were reading the strings from.
2024-10-28terminal: refactor hyperlink memory managementMitchell Hashimoto
Fixes #2500 Based on #2508 This separates out the concept of a "hyperlink" from a "hyperlink page entry." The difference is that the former has real Zig slices into things like strings and the latter has offsets into terminal page memory. From this separation, the Page structure now has an `insertHyperlink` function that takes a hyperlink and converts it to a page entry. This does a couple things: (1) it moves page memory management out of Screen and into Page which is historically more appropriate and (2) it let's us more easily test hyperlinks from the Page unit tests. Finally, this PR makes some error sets explicit.
2024-07-22terminal: page clone handles case where hyperlink can't dupeMitchell Hashimoto
Fixes #1991 To check if a hyperlink from another page is already present in our page's set, we need to dupe the hyperlink struct. If the hyperlink is already present in our page, this dupe is a waste and is freed. In the case where the hyperlink is present AND we don't have enough memory to dupe the hyperlink to check if its present, we'd previous simply crash out and fail rendering. Debug builds would crash with integrity errors. This commit resolves the issue by falling back to a slow path when our string allocation table is full and iterating over the hyperlink map to check one by one if we have the hyperlink. This O(N) is much slower than allocating (in this case) but N is usually low on top of this case being rare. A better solution would probably be to ensure we always have some % of available space free in our string allocation table. This would result in some wasteful page reallocs but would speed up the render loop. We can look into that later.
2024-07-05terminal: page clone needs to clone stringsMitchell Hashimoto
2024-07-05terminal: hyperlink deleted callback frees string memoryMitchell Hashimoto
2024-07-05terminal: hyperlink start/end on screenMitchell Hashimoto
2024-07-05terminal: hyperlink data structures beginning, alloc into pageMitchell Hashimoto