From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Multibyte and unibyte file names Date: Fri, 25 Jan 2013 09:37:52 +0200 Message-ID: <83k3r1lnlb.fsf@gnu.org> References: <83ehhbn680.fsf@gnu.org> <83wqv2ldk1.fsf@gnu.org> <83obgel94c.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1359099502 12028 80.91.229.3 (25 Jan 2013 07:38:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jan 2013 07:38:22 +0000 (UTC) Cc: kzhr@d1.dion.ne.jp, michael.albinus@gmx.de, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 25 08:38:41 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tyds0-0003Sl-2b for ged-emacs-devel@m.gmane.org; Fri, 25 Jan 2013 08:38:40 +0100 Original-Received: from localhost ([::1]:59411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tydri-0001vv-JA for ged-emacs-devel@m.gmane.org; Fri, 25 Jan 2013 02:38:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tydrf-0001uy-2r for emacs-devel@gnu.org; Fri, 25 Jan 2013 02:38:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tydrb-0004M5-Ck for emacs-devel@gnu.org; Fri, 25 Jan 2013 02:38:19 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tydrb-0004LE-4F for emacs-devel@gnu.org; Fri, 25 Jan 2013 02:38:15 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MH600A007Q9N500@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 25 Jan 2013 09:37:46 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH600AXY7UYCF80@a-mtaout22.012.net.il>; Fri, 25 Jan 2013 09:37:46 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:156628 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org, kzhr@d1.dion.ne.jp, michael.albinus@gmx.de > Date: Thu, 24 Jan 2013 19:06:56 -0500 > > >> > So you are saying that each primitive should detect unibyte file names > >> > it gets as arguments and DECODE_FILE them right away? > >> I think not: I was talking about decoding the file names *returned* > >> by primitives. > > What would be the difference, from the POV of the callers of the > > primitives? > > That the callers get to see meaningful (decoded) names? > That file-name manipulation functions don't have the side effect of > encoding/decoding file names? If we decode unibyte file names at entry to each primitive, before doing anything else, and thereafter manipulate decoded multibyte strings, this will happen anyway. But since everybody (at least those who spoke) seem to think this is a w32 only problem, I will solve it for w32 only.