On Fri, Sep 19, 2008 at 11:40:40PM +0200, Martijn van Oosterhout wrote:
> On Fri, Sep 19, 2008 at 10:27:44AM +0200, Carsten Hey wrote:
> > This was caused by a change in libncurses5. Linking against libncursesw5
> > fixes this bug.
>
> Is this a portable solution or does this problem only exist on Debian.
> I've never seen this behaviour before... I also saw reports of the next
> version of ncurses doing away with the wide version?
Hmm, good point. At least for soname version 5 in Debian linking against
ncursesw solves this bug. The following changes by ncurses' upstream changed
the behaviour of the non-wide version and thus caused this bug:
20080203
+ modify _nc_setupscreen() to set the legacy-coding value the same
for both narrow/wide models. It had been set only for wide model,
but is needed to make unctrl() work with locale in the narrow model.
+ improve waddch() and winsch() handling of EILSEQ from mbrtowc() by
using unctrl() to display illegal bytes rather than trying to append
further bytes to make up a valid sequence (reported by Andrey A
Chernov).
+ modify unctrl() to check codes in 128-255 range versus isprint().
If they are not printable, and locale was set, use a "M-" or "~"
sequence.
AFAIK there will be only one libncurses6 in Debian (instead of libcurses6 and
libncursesw6) which will be wide, so this might indeed be a Debian specific
problem. I don't know how other distributions handle this but I think you are
right and it is currently not a good idea to let pal link against ncursesw per
default.
Regards,
Carsten
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
