On 2023-01-03 13:06:38 +0100, Aurelien Jarno wrote: > Do you mean having a strict dependency on the major glibc version? That > sounds like an additional pain for new glibc releases, given how GNU > screen is developed upstream. And screen has an udeb, so it's not easy > to remove it from testing if it gets in the way.
This is what I meant, and I thought that this was easy enough to update the tables, so that there would be no need to remove screen from testing. But... > An alternative is to not try to support all systems and reinvent the > wheel, and instead assume a POSIX system. That way the attached patch > can be used. Thanks for the patch. I hope I can find some time later today to try it. I agree that the standard wcwidth() should be used for Debian, at least by default. I can see 2 reasons not to use wcwidth(): 1. On some systems (Solaris?), wcwidth() is broken. But if upstream still wants to support broken implementations, I think that using hardcoded tables should not be the default (so issues with obsolete tables would not affect Debian), and a fallback could be done like what xterm does, AFAIK. 2. East-Asian users who use mixed locales (are there still any?), where the width inside screen is different from the width for the real terminal (xterm, etc). Support for such configurations is what the cjkwidth option does. However, I don't see how this could work reliably with ncurses applications. Perhaps upstream would want to keep that support, like in (1). In any case, this is not the default. For the reference: https://savannah.gnu.org/bugs/index.php?16666 Note: In the screen Git log, there are no mentions of wcwidth, so it seems that it is not used just because it has never been added until now (I could see this in various versions of encoding.c), not because there is any issue with it. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
