From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong Date: Fri, 30 Nov 2012 15:55:45 +0200 Message-ID: <8338zrurdq.fsf@gnu.org> References: <7FC6A56C048B4EEAAE8EF71367793001@us.oracle.com> <87d2yvute9.fsf@web.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1354283828 32417 80.91.229.3 (30 Nov 2012 13:57:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2012 13:57:08 +0000 (UTC) Cc: lekktu@gmail.com, 13033@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 30 14:57:20 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TeR5j-0003yT-3N for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Nov 2012 14:57:19 +0100 Original-Received: from localhost ([::1]:44108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TeR5X-0000zq-AC for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Nov 2012 08:57:07 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TeR5U-0000zT-Ex for bug-gnu-emacs@gnu.org; Fri, 30 Nov 2012 08:57:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TeR5N-0002dB-E6 for bug-gnu-emacs@gnu.org; Fri, 30 Nov 2012 08:57:04 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TeR5N-0002d1-Aa for bug-gnu-emacs@gnu.org; Fri, 30 Nov 2012 08:56:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TeR7O-0004lf-AO for bug-gnu-emacs@gnu.org; Fri, 30 Nov 2012 08:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Nov 2012 13:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13033 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13033-submit@debbugs.gnu.org id=B13033.135428389318261 (code B ref 13033); Fri, 30 Nov 2012 13:59:02 +0000 Original-Received: (at 13033) by debbugs.gnu.org; 30 Nov 2012 13:58:13 +0000 Original-Received: from localhost ([127.0.0.1]:46417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeR6a-0004kR-C9 for submit@debbugs.gnu.org; Fri, 30 Nov 2012 08:58:12 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59872) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TeR6V-0004k3-GS for 13033@debbugs.gnu.org; Fri, 30 Nov 2012 08:58:09 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MEA00J00ZXWJN00@a-mtaout22.012.net.il> for 13033@debbugs.gnu.org; Fri, 30 Nov 2012 15:56:00 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEB00INR01BTDG0@a-mtaout22.012.net.il>; Fri, 30 Nov 2012 15:56:00 +0200 (IST) In-reply-to: <87d2yvute9.fsf@web.de> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67658 Archived-At: > From: Michael Heerdegen > Date: Fri, 30 Nov 2012 14:12:14 +0100 > Cc: 13033@debbugs.gnu.org > > Juanma Barranquero writes: > > > On Thu, Nov 29, 2012 at 10:44 PM, Drew Adams wrote: > > > > > In this Emacs version, > > > (read-file-name-internal "~" 'file-exists-p nil) returns "~/dradams/". > > > > read-file-name-internal's docstring clearly says: "Internal > > subroutine for `read-file-name'. Do not call this." > > I'm not sure if I understand the implications. I thought something like > "Do not call this." is meant for the end users, but also for developers? It means "don't call it from Lisp applications outside basic Lisp packages that come with Emacs." If that is a limitation, then I suggest to request additional APIs or extension of existing APIs, to cover the features which you miss in the current code base and that prompted you to use this function. > Emacs is the "extensible ... editor". It is quite difficult for any > developer to extend Emacs and contribute packages if we only allow the > use of high-level public interface functions. If that is true, then Emacs lacks some public APIs that should be added or extended. Using internal functions is not the way. > If we start to change our habits and write Emacs in a way that essential > primitives aren't allowed to be called by developers, this is the > beginning of the end of extensibility. Most primitives _are_ allowed to be called. But when you see something like "internal use only, don't call", that is not something you should ignore, because whoever wrote that had something serious in their minds. > It is a bug if something like `read-file-name-internal' is not > allowed to be called in third-party packages. Then please submit bug reports, asking for features that you cannot get from other APIs. > At university I learned that writing software happens in a way that > every function should have a clear specification for what it > does/returns, and a documentation of this. If they didn't teach you about the difference between internal APIs and public APIs, then it's too bad. Nevertheless, the distinction is part of our lives. Some languages have means to conceal private APIs from external applications, but C and Emacs Lisp don't. So we use whatever we got; please always assume that there are good reasons for that. (It is OK, of course, to question those reasons, but ignoring them is not wise, IMO.)