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: Changes in dos-fns.el Date: Fri, 14 May 2010 15:39:07 -0400 Message-ID: References: <83y6fm2y4f.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1273865961 27663 80.91.229.12 (14 May 2010 19:39:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 14 May 2010 19:39:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 14 21:39:20 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 1OD0j9-0006zC-ON for ged-emacs-devel@m.gmane.org; Fri, 14 May 2010 21:39:20 +0200 Original-Received: from localhost ([127.0.0.1]:41890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OD0j9-00075T-FK for ged-emacs-devel@m.gmane.org; Fri, 14 May 2010 15:39:19 -0400 Original-Received: from [140.186.70.92] (port=58517 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OD0j3-00075E-AK for emacs-devel@gnu.org; Fri, 14 May 2010 15:39:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OD0j1-0005G5-TI for emacs-devel@gnu.org; Fri, 14 May 2010 15:39:12 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:32867 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OD0iz-0005Fd-4B; Fri, 14 May 2010 15:39:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALND7UvO+LdN/2dsb2JhbACeBHK9doUQBIwv X-IronPort-AV: E=Sophos;i="4.53,232,1272859200"; d="scan'208";a="64239109" Original-Received: from 206-248-183-77.dsl.teksavvy.com (HELO pastel.home) ([206.248.183.77]) by ironport2-out.pppoe.ca with ESMTP; 14 May 2010 15:39:08 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C6CB78038; Fri, 14 May 2010 15:39:07 -0400 (EDT) In-Reply-To: <83y6fm2y4f.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 May 2010 20:26:24 +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-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:124777 Archived-At: > 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? My Emacs somehow loaded dos-fns.el and became largely unusable as a result. The loading was triggered by experimental code which provides completion for all variables, whether their package is already loaded or not. > 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. Well, I did complain, in the form of a patch. > Why is this suddenly an issue now? Because I suddenly bumped into the problem. > 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? Because I haven't bumped into them yet, I guess. > 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. By all means, fix it better. I agree that the "defalias" in dos-fns.el is really not a good solution to the problem. It was just a quick fix. > 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. My completion of functions and vars in not-yet-loaded packages works better if the packages follow the usual namespace convention. > 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? Feel free to add an obsolete-alias, then. > Unless I miss some very important aspects of this, I really, REALLY > think we should revert these changes. Following naming conventions is important, and following the "loading a file should be harmless" convention is important as well. It's difficult to impose those conventions across the board, but when we do bump into code that breaks them, we should always try and fix it. Undoing this change would be a step backward, but as DOS maintainer feel free to improve my change. Stefan