From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: locate-file in Emacs Date: Thu, 18 Apr 2002 14:59:14 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200204181859.g3IIxEY04890@rum.cs.yale.edu> References: <200204170928.g3H9SVb27019@rum.cs.yale.edu> <200204171001.g3HA1hh27230@rum.cs.yale.edu> <200204181408.g3IE83b02114@rum.cs.yale.edu> <200204181527.g3IFRFC02843@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019156612 27746 127.0.0.1 (18 Apr 2002 19:03:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 18 Apr 2002 19:03:32 +0000 (UTC) Cc: "Stefan Monnier" , emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16yHBs-0007DP-00 for ; Thu, 18 Apr 2002 21:03:32 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16yHVA-0000NW-00 for ; Thu, 18 Apr 2002 21:23:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16yH8r-0002iA-00; Thu, 18 Apr 2002 15:00:25 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16yH7j-0002bS-00 for ; Thu, 18 Apr 2002 14:59:15 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g3IIxEY04890; Thu, 18 Apr 2002 14:59:14 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Hrvoje Niksic Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2752 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2752 > I don't agree with that. At least, I wouldn't obsolete them for > XEmacs. I think they're quite useful, and much faster than the > generic PREDICATE. The useful part is not relevant: `executable' is not much better than `file-executable-p' for people writing code. Now the performance issue is something new that I haven't thought about too much. The only case where it matters seems to be when predicate is `file-executable-p' (since it seems to be the only MODE in use that I can see, apart from the default). How significant is it ? I truly do not know. > > I have no doubt that it's been used, so do you happen to know if it > > has been used in packages that are in active use ? > I have no statistics about that. Anectodes, maybe ? When I said active use, I meant a package that can be downloaded from the web as opposed to someone's .emacs file. Whether it's used by a million people or just by 5 doesn't matter too much at this stage. > > Based on the information here, I think I'll go ahead and implement > > the functionality on top of `openp' with just a `predicate' argument > > and without backward compatibility for `mode'. > > Please name your function differently to avoid confusion. I am > beginning to regret bringing this up. No, it would be silly not to have compatible interfaces. [ Note that my current implementation accepts `1' as predicate to mean file-executable-p (more or less, since it uses the `access' syscall, so it's actually as fast as the previous code and more importantly behaves the same). ] > > But I have one question left: should the `file-directory-p' check be enforced > > independently from `predicate' ? > > Yes, please. For several days I ran my `locate-file' in place of > XEmacs's original (to shake out the bugs), and I noticed that > `sh-script' wouldn't load. That is because my locate-file found > contains "packages/sh-script" (a directory) before > "packages/sh-script/lisp/sh-script[.elc]" (a file). I didn't mean to change the existing behavior, but I meant "when a predicate is passed what should happen" ? In any case, it seems there is some common agreement that directories should be ignored not matter what the predicate says. > > I.e. can (locate-file f p s 'file-readable-p) return a directory ? > > > > "Yes" is better since it allows the caller to choose whether > > directories are considered or not but "no" is better because it > > allows (locate-file file path suffixes 'file-executable-p) to behave > > like your current (locate-file file path suffixes 'executable). Or > > does the current XEmacs code always consider directories anyway ? > > I think it is ok for a function named `locate-file' to ignore > directories. That's true, but I was just thinking of the case where someone needs to look through a path for a particular subdirectory. Like look for the X11 subdirectory in /usr/include:/usr/X11R6/include:/usr/local/include:/usr/share/include:... It would be convenient to be able to use locate-file for it as well just by passing an appropriate predicate. Stefan