From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: 23.0.60; Can't start emacs when filename contains national character Date: Sat, 29 Mar 2008 23:54:26 +0300 Message-ID: References: <47EDA753.4030107@gmail.com> <87od8x67r5.fsf@gmx.de> <87wsnl4miu.fsf@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1206824084 24499 80.91.229.12 (29 Mar 2008 20:54:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2008 20:54:44 +0000 (UTC) Cc: lekktu@gmail.com, lennart.borgman@gmail.com, svenjoac@gmx.de, emacs-pretest-bug@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 29 21:55:14 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jfi54-0003IT-8K for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 21:55:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jfi4S-00079p-NY for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 16:54:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jfi4P-00079c-4W for emacs-devel@gnu.org; Sat, 29 Mar 2008 16:54:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jfi4M-00079Q-Nn for emacs-devel@gnu.org; Sat, 29 Mar 2008 16:54:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jfi4M-00079N-Hc for emacs-devel@gnu.org; Sat, 29 Mar 2008 16:54:30 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jfi4M-0001Ii-BB for emacs-devel@gnu.org; Sat, 29 Mar 2008 16:54:30 -0400 Original-Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1Jfi4L-0007kb-UT for emacs-pretest-bug@gnu.org; Sat, 29 Mar 2008 16:54:29 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Jfi4I-0001IC-Ln for emacs-pretest-bug@gnu.org; Sat, 29 Mar 2008 16:54:29 -0400 Original-Received: from heller.inter.net.il ([213.8.233.23]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jfi4I-0001Hy-Ac for emacs-pretest-bug@gnu.org; Sat, 29 Mar 2008 16:54:26 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-21-101.inter.net.il [80.230.21.101]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id FJG03016 (AUTH halo1); Sat, 29 Mar 2008 23:54:23 +0300 (IDT) In-reply-to: (message from Stefan Monnier on Sat, 29 Mar 2008 16:22:53 -0400) X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:93835 gmane.emacs.pretest.bugs:21779 Archived-At: > From: Stefan Monnier > Date: Sat, 29 Mar 2008 16:22:53 -0400 > Cc: lekktu@gmail.com, lennart.borgman@gmail.com, svenjoac@gmx.de, > emacs-pretest-bug@gnu.org > > > That's what I did eventually. I tried to be smart at first, to maybe > > avoid the overhead of full-fledged decoding, but gave up and used > > DECODE_FILE instead. > > If the issue is performance, maybe we should just improve > (en|de)code-coding-string to recognize those few special cases and > redirect them to string-(to|as)-(uni|multi)byte. I'm not sure it's warranted: we do something like if (STRING_MULTIBYTE (foo)) foo = ENCODE_FILE (foo); in quite a few more places, so it's probably efficient enough. It's just that en/decode_coding is so scarily large, while string-to/make-* are so seductively compact and simple...