This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7.1 release date?


Andy Koppe schrieb:
Charles Wilson wrote:
I think the major
concern is, do you guys (the folks most versed in the charset/lang
issues) think that the charset/lang stuff is good enough (even if not
perfect) for a release?

I think so, but there will be complaints: - It's a common assumption that the "C" locale implies ASCII, which isn't the case for Cygwin 1.7. Solution: use C.ASCII instead. - There may be more cases of apps being stumped at the sight of "C.UTF-8". Solution: use your actual locale such as "en_US.UTF-8" instead. - Some apps shipped with Cygwin aren't yet UTF-8-ready. Solution: wait for an update. Meanwhile, run them with with the singlebyte charset of your choice, e.g. "C.CP1252".

However, these are much smaller problems than having no Unicode
support at all. Cygwin 1.7 is a huge step forward.


I'm thinking of the recent discussion concerning ^H vs.
^?. I've still got a patch in my queue for terminfo, so I'd like to
roll that out before/simultaneously with cygwin-1.7.1

That would be great. Unfortunately we've created a bit of a mess with
console and mintty using ^? while xterm and rxvt still use ^H.
urxvt (rxvt-unicode) uses ^?, and xterm could be adjusted to use ^? in /etc/X11/app-defaults.

Thomas Wolff:
I think this stuff is working quite well now, with one small but significant
issue: I had suggested to add set LC_CTYPE=C.UTF-8 to cygwin.bat and I'd
like to strongly repeat this suggestion as it might avoid much trouble.
I agree, although the X issue with C.UTF-8 put some doubt in my mind.
Emacs certainly misbehaves without this, though, which makes it seem
likely that other apps do too.

Hoever, I think it should be 'set LANG=C.UTF-8', because LC_CTYPE
would override a user's LANG setting on the command line. That may get
quite frustrating if they're not aware of the LC_CTYPE setting.
As far as I know LANG is a variable predating the LC_ variables in usage, so very few people might know it and not the others, but some other people might know LC_* and not LANG.
I think using LC_CTYPE here is better because it's more specific whereas LANG is a generic catch-all setting. Someone might set LC_MESSAGES=gr to get Greek messages, without caring about the charset here. If that was configured with LC_CTYPE, all is well and they can happily coexist, getting Greek messages in the terminal charset. If it was configured with LANG, it would be overridden and terminal handling would break.


Thomas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]