From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: convert-standard-filename Date: Sun, 07 Aug 2011 16:19:47 -0400 Message-ID: References: <83vcufaaqf.fsf@gnu.org> <83hb5vvwdp.fsf@gnu.org> <834o1t19hg.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312748492 10432 80.91.229.12 (7 Aug 2011 20:21:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2011 20:21:32 +0000 (UTC) Cc: sds@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 07 22:19:56 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qq9pD-0001LQ-Ic for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2011 22:19:55 +0200 Original-Received: from localhost ([::1]:55305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qq9pC-0007xD-UC for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2011 16:19:54 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qq9pA-0007x2-2F for emacs-devel@gnu.org; Sun, 07 Aug 2011 16:19:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qq9p8-0002bp-RM for emacs-devel@gnu.org; Sun, 07 Aug 2011 16:19:52 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:19862 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qq9p7-0002bO-CQ; Sun, 07 Aug 2011 16:19:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGvyPk5FxKeo/2dsb2JhbABCpzR4gUABAQQBViMQCy0HEhQYDSSIALh7gzmDDQSfVYQx X-IronPort-AV: E=Sophos;i="4.67,333,1309752000"; d="scan'208";a="129446278" Original-Received: from 69-196-167-168.dsl.teksavvy.com (HELO ceviche.home) ([69.196.167.168]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 07 Aug 2011 16:19:47 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 50FEC66386; Sun, 7 Aug 2011 16:19:47 -0400 (EDT) In-Reply-To: <834o1t19hg.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 Aug 2011 19:18:03 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:142974 Archived-At: >> >> But how should it decide what is relative and what is not, e.g. in the >> >> case of "c:/foo" (or worse "c:foo") mentioned in the docstring? >> > Why by file-name-absolute-p, of course ;-) >> This would mean that the input is interpreted in an OS-dependent way. >> It would seem to make more sense to say that the arg to >> convert-filename-argument (or its new replacement) should be >> a Unix-style filename, i.e. "C:" is always interpreted as >> a relative file name, even under Window or DOS. > Although it makes sense, that would change the current semantics, and > probably break some existing code out there. Agreed. I think that not only convert-standard-filename has drifted far from its original purpose, but to fix it we need to define a new function because too many callers require a behavior that's incompatible with "the right convert-standard-filename". >> How 'bout a file-name-equal, which could also try to account for >> case-sensitivity? > He-he, I was arguing for years that file names are not strings and > cannot be compared as strings. Finally I have someone who agrees ;-) I always thought you weren't completely convinced. I'm all for it. We do want to define it carefully, tho. E.g. it should only operate on names without performing any actual file/directory lookup. >> Hmm... I didn't check all uses of doc-8+3-filename, but at least the one >> in files.el can't be replaced by file-name-equal. > They all can. dos-8+3-filename was introduced _only_ to be able to > compare and match file names as strings. The use in files.el is to generate a good backup file name, presumably because "#foobar.perl#" would get turned into "#foobar.per" whereas we prefer "#foobar.pe#". I don't know how to do that with file-name-equal, but admittedly, dos-8+3-filename is not sufficient to do it either: it uses ad-hoc code in files.el. Stefan