From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12287 invoked by alias); 13 Feb 2017 22:03:17 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 12279 invoked by uid 89); 13 Feb 2017 22:03:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=erases, apparently, erase, H*MI:sk:2017013 X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.75) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Feb 2017 22:03:15 +0000 Received: from [192.168.178.45] ([95.91.244.74]) by mrelayeu.kundenserver.de (mreue104 [212.227.15.183]) with ESMTPSA (Nemesis) id 0MMFUT-1clNL30p1J-007zZI for ; Mon, 13 Feb 2017 23:03:12 +0100 Subject: Re: [ANNOUNCEMENT] Updated: dash-0.5.8-3 To: cygwin@cygwin.com References: <58893f48.0850ca0a.6c5d.5fde@mx.google.com> <81b5af354b7a3925ff0a68dcc063265f@smtp-cloud6.xs4all.net> <20170131100402.GB29504@calimero.vinschen.de> <20170131131616.GC29504@calimero.vinschen.de> <40c92f1e987a9162742766816abb4a03@smtp-cloud2.xs4all.net> <20170131153245.GA8905@calimero.vinschen.de> From: Thomas Wolff Message-ID: <09c7b42a-7b8d-52b7-ce18-4e681eb51f05@towo.net> Date: Mon, 13 Feb 2017 22:03:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170131153245.GA8905@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:ZAqZGNhLaiE=:qgd7A29TXtx+TB5bFs1GBs jVjwRAoSNuQHdq2Rg0zTJHFBlGL6IhnHab+B7jzS9IIyXfj/OTz23QjUYBBNhquZciffroAcB viXEw868nqnuq82i9soEuz9LkFAW4AA05WhTyrxlShre3x8QOx+O7YqSI8Jn9vek5JO2FAVKh yT/IqzP++iawJvu/LM+dVNiaoLOIhexGXo1sh1Sb6FKdSdNwZiQchzL5GnNEByb468I9uMjpz /uB59IWhUR4JfKdHDG4YTBY4Jt833+vyA15evss6Vg9Z8ZWjcAI3Fq9hMB1o3xTfwqvSu+RXc 4gPVzgD6IcKGdQqBoy1eJq9J2mA4uTDXTpaxfBEy1FtfhVct7Bc1RRXRGsU6CPdKs6vxYv4px tuy3CaHMv6jfoco6yQtb2KgCisgBBPsrIDPpxc4EsJgVr/tKfDT5MkB08Lnratcn7hOfkCUcn 4SZdWwKBhjPlU4c9pur1mz/cO5ZQif1OLybNUJ07oorltIcyifbxpiKes6SY7ULs72syJKRoF J+Q3JBNMAZKtMjSrkkXGxn+39tAIwLh1tRb5tC5UwOTaLjDz8OPz6XsjcScPi8yChlcF4Uewu Y23ZxbWkMJFaTKVMgPzOAobmIghK9S2eclFnH5J87h+2VAmyrnYxvBO6Bm2Fq08V43L2NgyES V8EbDzMbFDajqJNf6VL6UAc5XaMM5RLdm+buoufub89iWDS7YAS6HjlB1Xjq2jKQkzexlhXfw I58bUIq/ni1RMilW X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00181.txt.bz2 Am 31.01.2017 um 16:32 schrieb Corinna Vinschen: > On Jan 31 16:01, Houder wrote: >> On Tue, 31 Jan 2017 14:16:16, Corinna Vinschen wrote: >> >> [snip] >> >>>> I'm not quite sure yet but apparently the problem is in the handling of >>>> VERASE in the termios implementation. In cooked mode it fills a char >>>> buffer with what has been typed. The code doesn't know if the bytes in >>>> the buffer are UTF-8 chars or just random bytes. So VERASE erases >>>> exactly one byte, which means, in case of UTF-8 chars it only erases the >>>> last byte of of a mulitbyte character. >>>> >>>> ... >>> Ok, here's what happens on Linux: The termios code support a flag >>> IUTF8. This flag determines if the termios code checks for UTF8 >>> characters in the input when performing an ERASE. It checks if the >>> IUTF8 flag is set and if so, it checks in a loop if the just erased byte >>> is a UTF-8 continuation character. If so, it erases another byte. >> Agreed. One byte or more, depending on the "character" ... (which is >> not a problem in case of UTF-8 encoding -- continuation bit). >> >> Of course, the terminal driver must receive the characters encoded in UTF-8. >> >> ... > ... It's the termios implementation > inside Cygwin. I created a patch introducing the IUTF8 flag as on Linux > as well as a code snippet trying to remove entire utf-8 characters from > the input if the IUTF8 flag is set. And it's set now by default since > we default to UTF-8 anyway. > > Thomas, you may want to check for the IUTF8 flag in upcoming mintty > versions and unset it if character set configured in the mintty options > dialog is != UTF-8. So the flag is always set initially? Also on Linux? Does it (on Linux) also have an effect for non-UTF-8 multibyte encodings? And cannot the Cygwin DLL set the flag to match the locale setting when it was invoked? I can (and will if appropriate) handle the flag in mintty as needed, but what if someone calls LC_ALL=.other_encoding dash later within the terminal session? I guess the more consistent solution would be to handle this in the cygwin DLL. ------ Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple