On Tue, Feb 12, 2002 at 02:33:20PM -0500, Thomas E. Dickey wrote: > ...and it's trivial to redefine it with a wrapper.
And any other ncurses calls that take text. This, presumably, won't be needed once the regular (non-wide) functions are multibyte-aware; the slang patch is just a stopgap until that's ready. > my point: the number of people who actually follow up with proposed > patches I can count on one hand - while I've lost track of the people who > stand around waiting for someone else to do the work. I'm saying why I think Mutt acts like it does; I'm not proposing it be changed. I'm fine with leaving it alone until ncursesw is done. Mostly. I'm not excited about it being the way it is in the next Debian release, since that means a lot of people will be stuck with it; if there's anything that'll get me to write a patch intended to be removed shortly after, it's that. By the way, ncurses(3X): > The ncurses library is intended to be BASE-level conformant with the XSI Curses > standard. Certain portions of the EXTENDED XSI Curses functionality > (including color support) are supported. The following EXTENDED XSI Curses > calls in support of wide (multibyte) characters are not yet implemented: ... addstr isn't in this list, so I assume this is a list of missing wide support, not multibyte; perhaps "(multibyte)" should be removed so this doesn't imply that multibyte is implemented? > > The slang patch is almost drop-in, so it's an easy stopgap until multibyte > > support is in ncurses mainstream. (I'm assuming that the "ncursesw" naming > > is temporary, until it's fully implemented.) It just needs a couple > > actually the more I look at it, the better it looks from the standpoint > of compatibility - not that this is guaranteed to have much impression > on bulk packagers. (I understand that slang users cannot possibly be > concerned about compatibility - or else they haven't thought very long > about it). Er, what looks better for compatibility with what? The slang patch is horrible for compatibility (it's not binary-compatible, not quitesource- compatible, though most programs wouldn't notice, and it's a bit ugly.) Do you mean that leaving wide and multibyte support in its own library is better for compatibility? I'd hate to see that, at least for multibyte support--which, presumably, would depend on wide support. What problems could that cause? (Programs that aren't locale-aware won't setlocale(), so the behavior should be unchanged.) -- Glenn Maynard -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
