Emojis in messages and/or node names cause crashes depending on screen width #58

Closed
opened 2026-10-05 03:18:08 +02:00 by adam · 3 comments
Owner

Emojis (on my system?) take up two characters of space in the terminal, but our logic treats them as one character, which means (depending on window size and wrapping points) we can end up trying to draw out of bounds and crash. We need to somehow account for > 1 character widths in drawing.

Emojis (on my system?) take up two characters of space in the terminal, but our logic treats them as one character, which means (depending on window size and wrapping points) we can end up trying to draw out of bounds and crash. We need to somehow account for > 1 character widths in drawing. <!-- github-sync-id:3118511002 -->
adam closed this issue 2026-10-05 03:18:08 +02:00
Author
Owner

the wcwidth package can handle this I believe but it'd be nice to not require more packages. I haven't seen a crash from this issue but I've seen the columns misalign. It's also an issue with the cli's --nodes display. I'm not sure of the best way to proceed.

the wcwidth package can handle this I believe but it'd be nice to not require more packages. I haven't seen a crash from this issue but I've seen the columns misalign. It's also an issue with the cli's `--nodes` display. I'm not sure of the best way to proceed. <!-- github-comment-id:2951742248 -->
Author
Owner

Note reproducing a crash is quite easy - either send or receive a message consisting of, say, 30 emojis (I'm using "🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭"). After this, selecting the chat that has the emojis in it with a small-ish window size will crash every time. Expanding the window large enough prevents crashing.

I think I'm usually getting the crash (without artificially trying to reproduce with a line of emojis) in chats where I've done a traceroute to a node with an emoji in the short name - trace routes produce enough output to reliably wrap, and contain the emoji at least twice, which is pretty much all you need in most cases.

I'm experimenting with ways to try to address this but wcwidth might be the best. Minimizing dependencies makes sense, and if it was just misalignment as in the cli's --nodes, I might think we could just deal with it, but given this leads to reliable crashes, an extra dependency may be the lesser of the two evils.

Note reproducing a crash is quite easy - either send or receive a message consisting of, say, 30 emojis (I'm using "🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭🤭"). After this, selecting the chat that has the emojis in it with a small-ish window size will crash every time. Expanding the window large enough prevents crashing. I think I'm usually getting the crash (without artificially trying to reproduce with a line of emojis) in chats where I've done a traceroute to a node with an emoji in the short name - trace routes produce enough output to reliably wrap, and contain the emoji at least twice, which is pretty much all you need in most cases. I'm experimenting with ways to try to address this but wcwidth might be the best. Minimizing dependencies makes sense, and if it was just misalignment as in the cli's --nodes, I might think we could just deal with it, but given this leads to reliable crashes, an extra dependency may be the lesser of the two evils. <!-- github-comment-id:2954171341 -->
Author
Owner

It seems like a bit of a hack, but something like this might save us while not requiring adding additional dependencies:

https://github.com/tqdm/tqdm/pull/822/files#diff-a80e72b5f3679063ef2e742eba24c88112f0e189d34acc70cf2dc866e9af84b8R295

Sounds like the goal there was the same as ours - wcswidth specifically would be more ideal, but we'd prefer to avoid adding dependencies.

It seems like a bit of a hack, but something like this might save us while not requiring adding additional dependencies: https://github.com/tqdm/tqdm/pull/822/files#diff-a80e72b5f3679063ef2e742eba24c88112f0e189d34acc70cf2dc866e9af84b8R295 Sounds like the goal there was the same as ours - wcswidth specifically would be more ideal, but we'd prefer to avoid adding dependencies. <!-- github-comment-id:2954174288 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/contact#58