X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS,URIBL_RHS_DOB X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <200906121538.n5CFcSld014997@mail.bln1.bf.nsn-intra.net> References: <20090512165404 DOT GW21324 AT calimero DOT vinschen DOT de> <416096c60905120956n5521929bm69586f5e6325a994 AT mail DOT gmail DOT com> <20090512173153 DOT GY21324 AT calimero DOT vinschen DOT de> <3f0ad08d0905140858j17c7b374paa649f18ef18178d AT mail DOT gmail DOT com> <200905201652 DOT n4KGqYGm000509 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net> <200906051625 DOT n55GP6t3028411 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net> <3f0ad08d0906060242t275a78e7tb9913bf78d1c5e83 AT mail DOT gmail DOT com> <200906121538 DOT n5CFcSld014997 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net> Date: Sun, 14 Jun 2009 22:04:28 +0900 Message-ID: <3f0ad08d0906140604y49c470eeu68c6c307ec1cd073@mail.gmail.com> Subject: Re: [Fwd: [1.7] wcwidth failing configure tests] From: IWAMURO Motonori To: newlib AT sourceware DOT org, cygwin AT cygwin DOT com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 2009/6/13 Thomas Wolff : > I have checked source data files in /usr/share/i18n/charmaps on my Linux system, e.g. "UTF-8.gz". > character widths are the same for all locales with the same "charmap". It was reported as a bug, but it isn't fixed now...X-( http://sourceware.org/bugzilla/show_bug.cgi?id=4335 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471021 > If you think you can get your proposal passed "up-stream", > go ahead and try it, please! If you succeed, everything is fine. Hmmm, I think that you have misunderstood something because my explanation is bad. I called "up-stream" as the maintainance team of each OS, library, or application. I don't think that there is something single "up-stream". Japanese language users have tried to fix of the problem for many years, but it doesn't progress so much now. >> - In NetBSD, the change to which wcwidth of East Asian Ambiguous Characters returns 2 by CJK locale is planned. > So the same issue (of compliance and portability, especially in the > remote case) should be discussed in the NetBSD community. > (Is there a suitable forum or mailing list to check?) Sorry, I don't know it because I was personally advised by one of the NetBSD maintainer ( http://www.hi-matic.org/ (written in Japanese) ). >> I think that ALL locale implementations should treat East Asian >> Ambiguous Character Width as 2 for CJK locale. > Again, I agree that IF you manage to get ALL implementations to follow > this approach, the solution is fine. Please go ahead. I will do so, but I want to solve the problem on Cygwin first of all. >> How to detect it? The application using wcwidth is not necessarily >> executed with terminal emulator. (e.g. text formatter) > OK, my arguments refer to an interactive application that wants to > control the precise representation of text on the screen. > If for example a text formatter formats for paper printing, it would > need to apply completely different assumptions anyway. The dreadful > single/double width issue of cell-based terminals isn't relevant at > all in that case. I am assuming the application that depends on the fixed-pitch font as text-formatter. (like 'indent' command) I hope the following two results become the same. - the auto-format filter program using 'wcwidth'. - run auto-format command on editor. (e.g. "fill-paragraph", "indent-region", etc on Emacs) -- IWAMURO Motnori -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/