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: Changes in dos-fns.el Date: Fri, 14 May 2010 20:26:24 +0300 Message-ID: <83y6fm2y4f.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1273858723 789 80.91.229.12 (14 May 2010 17:38:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 14 May 2010 17:38:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 14 19:38:42 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1OCyqN-0006La-Tq for ged-emacs-devel@m.gmane.org; Fri, 14 May 2010 19:38:40 +0200 Original-Received: from localhost ([127.0.0.1]:32949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCyqN-0002id-55 for ged-emacs-devel@m.gmane.org; Fri, 14 May 2010 13:38:39 -0400 Original-Received: from [140.186.70.92] (port=42102 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCyeb-0002ZQ-Q5 for emacs-devel@gnu.org; Fri, 14 May 2010 13:26:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCyeZ-0004DB-0q for emacs-devel@gnu.org; Fri, 14 May 2010 13:26:28 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:50573) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCyeY-0004Cw-PR for emacs-devel@gnu.org; Fri, 14 May 2010 13:26:26 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L2F00E006W5XB00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 14 May 2010 20:26:25 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.206.56]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L2F00BKI73ZQOC0@a-mtaout20.012.net.il>; Fri, 14 May 2010 20:26:25 +0300 (IDT) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:124775 Archived-At: 2010-05-13 Stefan Monnier * dos-fns.el: Add "dos-" prefix for namespace control. (convert-standard-filename): Define as alias for dos-convert-standard-filename but only if applicable. The more I think about these changes, the less I like them. These functions are very old, some from 1996, others from 1994, and in all that time no one complained about them. What kind of use-case was important enough to change their names now in an incompatible fashion? Yes, I've read the comments about convert-standard-filename. Again, no one complained about what happens when someone loads dos-fns on other platforms. Why is this suddenly an issue now? And if its _is_ an issue, why it gets fixed only in dos-fns, not in other places where we have overriding definitions for this function? In any case, I could think of better ways of fixing this. For example, we could lump all the definitions in the body of a single function on file.el, each alternative conditioned by the underlying OS. But if I could somehow understand the motivation for the change of convert-standard-filename, I have no idea what are the advantages of renaming venerable functions such as intdos and mode4350. Can they really cause name clashes? And if they can, how come that didn't happen even once in the last 15 years? Besides, mode25 and mode4350 are documented in the manual, and I expect them to be fairly popular amongst DOS users (when I was one, I had a call to mode4350 in my .emacs). Why change the name now without leaving behind a defalias? Unless I miss some very important aspects of this, I really, REALLY think we should revert these changes.