From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-31336-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 9761 invoked by alias); 26 Apr 2013 14:54:37 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 31336
Received: (qmail 2980 invoked from network); 26 Apr 2013 14:54:35 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	SPF_HELO_PASS autolearn=ham version=3.3.2
Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts)
X-AuditID: cbfec7f4-b7faf6d00000189b-89-517a92cdb9da
Date: Fri, 26 Apr 2013 15:44:27 +0100
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: Subversion completion don't work with UTF8 (and other) file names
Message-id: <20130426154427.06972873@pwslap01u.europe.root.pri>
In-reply-to: <20130426123921.GT16210@xvii.vinc17.org>
References:
 <CAMfFmgG7zQy=iAa5S8Bc2Uvio0DVpeUEnZMZAobbvNRASeb7HA@mail.gmail.com>
 <20130426123921.GT16210@xvii.vinc17.org>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42I5/e/4Fd2zk6oCDSa1C1ocbH7I5MDoserg
	B6YAxigum5TUnMyy1CJ9uwSujFXv3Qq6eCp2TN/O0sB4lbOLkZNDQsBE4tb/L0wQtpjEhXvr
	2boYuTiEBJYySvw5cZcFwlnOJDHrwFlmkCoWAVWJ3ptT2UBsNgFDiambZjOC2CIC4hJn155n
	AbGFBfwkzi75BVbPK2AvsWPvAbAaTgFTiQPT74HFhQRqJdqfXWYFsfkF9CWu/v0EdYW9xMwr
	ZxghegUlfky+BzaTWUBLYvO2JlYIW15i85q3zBMYBWYhKZuFpGwWkrIFjMyrGEVTS5MLipPS
	cw31ihNzi0vz0vWS83M3MUJC8MsOxsXHrA4xCnAwKvHwOjpUBgqxJpYVV+YeYpTgYFYS4V1Y
	VRUoxJuSWFmVWpQfX1Sak1p8iJGJg1OqgXHitztZws1JFef/VrEGTT/EJ+XTpid2mjt6uVus
	wco1X0q90w48jbizv2unRriMQLbSEedrOxXXT+kUyPgdbTr/xvrV2y/vVvn3/t+M3syw81yc
	Isbrz1ku+PFj49J9SkdOKTUy3uJpNZh4vvr6PfcG31+fRX/s/MC8enGOSVtd5VRHb6YS+b1K
	LMUZiYZazEXFiQBShphxHwIAAA==

On Fri, 26 Apr 2013 14:39:21 +0200
Vincent Lefevre <vincent@vinc17.net> wrote:
> Since the error message is about native encoding (US-ASCII here,
> due to the LC_ALL=C) to UTF-8, it concerns a file that is in the
> repository with a non-ASCII filename (internal encoding is UTF-8).
> 
> A solution might be to retrieve the computed LC_CTYPE with the
> "locale" command, then before executing svn, do the following:
> 
> _ Unset LC_ALL
> _ Set LC_CTYPE to the locale determined above.
> _ Set every other LC_* and LANG environment variables to "C".

Unsetting all the LC_* variables (including LC_ALL) and setting only
LC_CTYPE and LANG should be good enough, shouldn't it?  Something like:

_comp_locale() {
   # This exports new locale settings, so should only
   # be run in a subshell.  A typical use is in a $(...).
   local ctype=${${(f)"$(locale 2>/dev/null)"}:#^LC_CTYPE=*}
   unset -m LC_\*
   [[ -n $ctype ]] && eval export $ctype
   export LANG=C
}

seems to do the trick here:

LANG=C
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=

I've actually lost track of which of the above we're trying to fix up
when we set the locale in this sort of case.  LC_COLLATE, certainly,
and I think LC_MESSAGES since otherwise we can't parse it (although
the disadvantage here is the output may be in a language the user
doesn't understand).

pws