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: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files) Date: Tue, 02 Aug 2011 22:12:40 +0300 Message-ID: <83vcufaaqf.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1312312500 12961 80.91.229.12 (2 Aug 2011 19:15:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2011 19:15:00 +0000 (UTC) Cc: sds@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 21:14: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 1QoKQZ-00025X-1o for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 21:14:55 +0200 Original-Received: from localhost ([::1]:47290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoKQY-0001Cw-CB for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 15:14:54 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoKQV-0001CK-AU for emacs-devel@gnu.org; Tue, 02 Aug 2011 15:14:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoKQU-0008Gk-2d for emacs-devel@gnu.org; Tue, 02 Aug 2011 15:14:51 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:56262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoKQT-0008Gc-Rk; Tue, 02 Aug 2011 15:14:50 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LPB00300EQ1TZ00@a-mtaout22.012.net.il>; Tue, 02 Aug 2011 22:14:44 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.48.51]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LPB003J6ESH8VG0@a-mtaout22.012.net.il>; Tue, 02 Aug 2011 22:14:42 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:142739 Archived-At: > From: Stefan Monnier > Cc: sds@gnu.org, emacs-devel@gnu.org > Date: Tue, 02 Aug 2011 14:57:15 -0400 > > > convert-standard-filename can be called on any file name, not just an > > absolute ones. Of course, it will only do what Sam wants if the file > > name begins with /cygdrive/, i.e. is absolute, but your assertion > > seemed to be more general than that. > > C-h f convert-standard-filename RET: > > FILENAME should be an absolute file name That's a lie: desktop.el:210: (convert-standard-filename ".emacs.desktop") desktop.el:216: (convert-standard-filename ".emacs.desktop.lock") dired-x.el:768:(defcustom dired-local-variables-file (convert-standard-filename ".dired") ido.el:924:(defcustom ido-save-directory-list-file (convert-standard-filename "~/.ido.last") ps-bdf.el:104: (convert-standard-filename "~/.bdfcache.el")) recentf.el:72:(defcustom recentf-save-file (convert-standard-filename "~/.recentf") saveplace.el:72:(defcustom save-place-file (convert-standard-filename "~/.emacs-places") shadowfile.el:805: (shadow-expand-file-name (convert-standard-filename "~/.shadows")))) shadowfile.el:809: (convert-standard-filename "~/.shadow_todo")))) strokes.el:260:(defcustom strokes-file (convert-standard-filename "~/.strokes") > since the conversion rules > sometimes vary depending on the position in the file name. E.g. c:/foo > is a valid DOS file name, but c:/bar/c:/foo is not. The example of a problem is correct, but the generalization is obviously invalid.