On Tue, Sep 05, 2006 at 06:34:00AM -0400, Thomas Dickey wrote: > btw, the report refers to someone's problems with mc, but that's usually > built with slang (the tie-in to ncurses is to satisfy a bogus linkage with > gpm).
You are right. But that bug report was expanded from that problem with mc (that uses slang) to ncurses, and to other problems related to ncurses (mp3blaster, tmsnc...) AND someone tried to open a new bug with a new ebuild with the ncurses problem, and someone closed it marking it as a copy of the original bug, that hadn't nothing to do with ncurses (as you said, it started because of a slang problem with mc). > > >If you think you have a solution, please tell us. > > not really (don't have GenToo, nor the time to maintain a copy). > The bug report _seems_ to be heading in the right direction. Well, some effort is being done of making all systems UTF-8 system wide, for some reasons, and that's the way it should be. For that reason all of us: from developers, to package maintainers and users should make some effort of creating some kind of standard. It would be very easy for all of us if we forget narrow ncurses (ISO-8859-* and friends) and we try only to get working wide ncurses. I've heard (I'm not so sure, because I haven't developed for ncurses) that wide ncurses is compatible with narrow ncurses, and the ebuild that is uploaded in that bug should be interesting, from the point of view that makes symlinks from narrow ncurses to wide ncurses, so the apps linked against narrow ncurses won't be hurt (they shouldn't need even be recompiled), and the apps that support wide ncurses would work normally. As you say that the bug report seems to be heading in the right direction, but take in count when it was opened, and today it hasn't been fixed yet, so maybe we have to make a bigger effort to fix it. Thank you, Rafael Fernández López. -- [email protected] mailing list
