On Mon, Jun 16, 2025 at 01:23:16AM +0000, zahlman via Bug reports for ncurses, the GNU implementation of curses wrote: ... > I'm not expecting ncurses to do any special-casing in the output of the > heart emoji - especially since different terminals are already > attempting their own, mutually incompatible workarounds etc. But I do > expect that it should send the text that it was given. Or at least that > inserting and overwriting text do the same thing when the line is blank > to begin with.
curses doesn't work that way. An application uses curses to write onto a virtual screen, from which curses will refresh/paint onto the physical terminal. As part of that process, it provides for wrapping at the right margin, and scrolling/indexing. In doing this, it knows about spacing and non-spacing characters. But ncurses uses wcwidth to know about that. There're basically two cases for putting data into the virtual screen in curses. One uses waddch, the other does not. In a quick check, it seems that wcwidth says the variation selector is a spacing character, so waddch will put that in a different cell. The absence of that check in the non-waddch path should be regarded as a defect (something to fix). The Unicode people blundered by requiring applications to redo their interpretation of a code, and compounded it by failing to get some workaround using standard functions such as wcwidth. If I've missed something, clarification would be helpful, but what I see is just something to work around, because the root cause is unlikely to be fixed. -- Thomas E. Dickey <[email protected]> https://invisible-island.net
signature.asc
Description: PGP signature
