dnkl/foot
41
2.0k
Fork
You've already forked foot
243

undercurl support #828

Closed
opened 2021年12月01日 19:22:16 +01:00 by psykose · 5 comments

undercurl is an alternate form of underline, with curls.
it looks like this in notcurses-info output on kitty: example from kitty.
on foot:
example from foot
i'm also curious what (削除) bce (削除ここまで)(erase with background color, apparently) and kbd are, but that doesn't matter here (or at all?)

undercurl is an alternate form of underline, with curls. it looks like this in notcurses-info output on kitty: ![example from kitty](https://img.ayaya.dev/DPFVbmHFFHsn.webp). on foot: ![example from foot](https://img.ayaya.dev/wOyVC4Ua8w8g.webp) i'm also curious what ~~`bce`~~(erase with background color, apparently) and `kbd` are, but that doesn't matter here (or at all?)
Owner
Copy link

Right now, we don't plan on implementing undercurlies. To do so would require us to add 4 bytes (to hold the curly's color) to each cell, which would increase run-time memory usage with ~33%.

kbd refers to the Kitty keyboard extension, and support for it is being worked on. Latest master has the initial bits, and there are PR's open for the next pieces, with more to come.

Right now, we don't plan on implementing undercurlies. To do so would require us to add 4 bytes (to hold the curly's color) to **each** cell, which would increase run-time memory usage with ~33%. `kbd` refers to the [Kitty keyboard extension](https://sw.kovidgoyal.net/kitty/keyboard-protocol/), and support for it is being worked on. Latest master has the initial bits, and there are PR's open for the next pieces, with more to come.
Author
Copy link

kbd refers to the Kitty keyboard extension,

ah, thank you!

To do so would require us to add 4 bytes (to hold the curly's color) to each cell, which would increase run-time memory usage with ~33%.

that sounds pretty bad- didn't know it would be. thank you for the information! in that case, feel free to disregard this until in the future where a better solution might be thought of.

> kbd refers to the Kitty keyboard extension, ah, thank you! > To do so would require us to add 4 bytes (to hold the curly's color) to each cell, which would increase run-time memory usage with ~33%. that sounds pretty bad- didn't know it would be. thank you for the information! in that case, feel free to disregard this until in the future where a better solution might be thought of.

Correct me if I'm wrong, but in absolute terms the increased memory usage wouldn't be that much.

On my 4k screen in foot I get 96 rows and 424 columns. So (96 rows) * (424 columns) * (4 bytes/cell) = 162,816 bytes = 0.163 megabytes.

So if you have a hundred instances of foot open you'd be using an additional 16.3 megabytes. On modern hardware that amount is negligible, and I think most users would trade the ram for undercurl support.

I get that foot is trying to be minimal, so maybe this feature could be enabled behind an option? Similar to #57

Correct me if I'm wrong, but in absolute terms the increased memory usage wouldn't be that much. On my 4k screen in foot I get 96 rows and 424 columns. So (96 rows) * (424 columns) * (4 bytes/cell) = 162,816 bytes = 0.163 megabytes. So if you have a hundred instances of foot open you'd be using an additional 16.3 megabytes. On modern hardware that amount is negligible, and I think most users would trade the ram for undercurl support. I get that foot is trying to be minimal, so maybe this feature could be enabled behind an option? Similar to https://codeberg.org/dnkl/foot/issues/57
Collaborator
Copy link

On my 4k screen in foot I get 96 rows and 424 columns. So (96 rows) * (424 columns) * (4 bytes/cell) = 162,816 bytes = 0.163 megabytes.

That's just for the visible grid though. If you include the (default) 1000 lines of scrollback it'd be 10x that. 1.6MB is still relatively small in terms of memory usage, but there's also cache usage to consider.

I'm kind of in favor of undercurls, since it's the most obvious styling for spelling errors in editors, but it seems a bit optimistic to say it'd only use 0.163MB.

> On my 4k screen in foot I get 96 rows and 424 columns. So (96 rows) * (424 columns) * (4 bytes/cell) = 162,816 bytes = 0.163 megabytes. That's just for the visible grid though. If you include the (default) 1000 lines of scrollback it'd be 10x that. 1.6MB is still relatively small in terms of memory usage, but there's also cache usage to consider. I'm kind of in favor of undercurls, since it's the most obvious styling for spelling errors in editors, but it seems a bit optimistic to say it'd only use 0.163MB.

Any updates on this? I saw #1099 but it hasn't been merged yet.

Any updates on this? I saw #1099 but it hasn't been merged yet.
Sign in to join this conversation.
No Branch/Tag specified
master
osc-5522
sixel-heap-buffer-overflow
releases/1.27
releases/1.26
releases/1.25
releases/1.24
multi-cursor
releases/1.23
pixman-16f-2
releases/1.22
releases/1.21
releases/1.20
releases/1.19
releases/1.18
releases/1.17
releases/1.16
releases/1.15
releases/1.14
releases/1.13
releases/1.12
releases/1.11
releases/1.10
releases/1.9
releases/1.8
releases/1.7
releases/1.6
releases/1.5
releases/1.4
releases/1.3
releases/1.2
releases/1.1
releases/1.0
1.27.0
1.26.1
1.26.0
1.25.0
1.24.0
1.23.1
1.23.0
1.22.3
1.22.2
1.22.1
1.22.0
1.21.0
1.20.2
1.20.1
1.20.0
1.19.0
1.18.1
1.18.0
1.17.2
1.17.1
1.17.0
1.16.2
1.16.1
1.16.0
1.15.3
1.15.2
1.15.1
1.15.0
1.14.0
1.13.1
1.13.0
1.12.1
1.12.0
1.11.0
1.10.3
1.10.2
1.10.1
1.10.0
1.9.2
1.9.1
1.9.0
1.8.2
1.8.1
1.8.0
1.7.2
1.7.1
1.7.0
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.0
1.2.3
1.2.2
1.2.1
1.2.0
1.1.0
1.0.0
0.9.0
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dnkl/foot#828
Reference in a new issue
dnkl/foot
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?