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: [Emacs-diffs] master 3431e82: Ignore directory symlinks in directory-files-recursively Date: Sun, 21 Dec 2014 22:02:40 -0500 Message-ID: References: <20141212105304.4186.22515@vcs.savannah.gnu.org> <87vbl5z03r.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1419217398 19563 80.91.229.3 (22 Dec 2014 03:03:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Dec 2014 03:03:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 22 04:03:11 2014 Return-path: Envelope-to: ged-emacs-devel@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 1Y2tH4-00050J-Qy for ged-emacs-devel@m.gmane.org; Mon, 22 Dec 2014 04:03:10 +0100 Original-Received: from localhost ([::1]:38913 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2tH4-0004ef-4w for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2014 22:03:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58741) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2tGj-0004eT-2x for emacs-devel@gnu.org; Sun, 21 Dec 2014 22:02:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y2tGb-0007IH-HK for emacs-devel@gnu.org; Sun, 21 Dec 2014 22:02:48 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:12611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2tGb-0007IB-DY for emacs-devel@gnu.org; Sun, 21 Dec 2014 22:02:41 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsPAOwQflTO+ILA/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQEGAQEBAR6QbweESAWLAaQugXiCN4FiIYJ3AQEB X-IPAS-Result: AjsPAOwQflTO+ILA/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQEGAQEBAR6QbweESAWLAaQugXiCN4FiIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="103139448" Original-Received: from 206-248-130-192.dsl.teksavvy.com (HELO pastel.home) ([206.248.130.192]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Dec 2014 22:02:40 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 627C71E41; Sun, 21 Dec 2014 22:02:40 -0500 (EST) In-Reply-To: <87vbl5z03r.fsf@building.gnus.org> (Lars Ingebrigtsen's message of "Sun, 21 Dec 2014 12:57:44 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.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:180459 Archived-At: >> It can avoid calling expand-file-name only to call file-name-directory >> (or file-name-nondirectory) right after. > It can, but in the use cases I've typically seen, you wouldn't do that, > I think? You'd say `(directory-name-p file)' and then... something... I don't understand what you mean here. I'm just pointing out that calling expand-file-name only to pass the result to the function parameter means that this work may be wasted. So passing the two parameters separately is a way to be more lazy. >> Can we reduce the number of arguments? > That would be nice, but I'm not sure what to remove. The canonical, > that most of the callers use (from the other versions of this function > included in various packages in Emacs) is > (directory-files-recursively "~/" "~\\'") > or something. And then there are a couple that want the directories, > too. And then there's `file-tree-walk', which is the new thing. Exactly: the use cases are varied, so we need a very generic interface. I actually find file-tree-walk not too bad in this respect. > Uhm... we could make MATCH be the predicate if it's not a string? But we need 2 answers: whether to include the file in the result, and whether to recurse. >>> (path (expand-file-name leaf dir))) >> This is not a "path", it's a file name. Remember: by convention >> a "path" is a list of directories, as in load-path, $PATH, etc... > Right. But do we have a word for "string that designates either a file > or a directory"? Yes, we say "a file name". A directory is a kind of file. > That's usually called "a path"... No, there are people who like to use "path" for other things, but the GNU convention is to only use it for "a list of directories, as in load-path, $PATH, etc...". Stefan