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: locate-dominating-file calls `stat' too eagerly Date: Mon, 29 Sep 2008 12:19:15 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1222705346 14333 80.91.229.12 (29 Sep 2008 16:22:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Sep 2008 16:22:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 29 18:23:23 2008 connect(): Connection refused 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.50) id 1KkLWg-000886-PK for ged-emacs-devel@m.gmane.org; Mon, 29 Sep 2008 18:23:11 +0200 Original-Received: from localhost ([127.0.0.1]:53265 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KkLVe-0004xn-36 for ged-emacs-devel@m.gmane.org; Mon, 29 Sep 2008 12:22:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KkLTA-000414-V3 for emacs-devel@gnu.org; Mon, 29 Sep 2008 12:19:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KkLT7-0003z3-DT for emacs-devel@gnu.org; Mon, 29 Sep 2008 12:19:32 -0400 Original-Received: from [199.232.76.173] (port=56106 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KkLT6-0003yq-Va for emacs-devel@gnu.org; Mon, 29 Sep 2008 12:19:28 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:60246) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KkLT0-0003Bq-Nc; Mon, 29 Sep 2008 12:19:23 -0400 Original-Received: from alfajor.home (vpn-132-204-232-94.acd.umontreal.ca [132.204.232.94]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id m8TGJlYS029669; Mon, 29 Sep 2008 12:19:47 -0400 Original-Received: by alfajor.home (Postfix, from userid 20848) id D585A1C18F; Mon, 29 Sep 2008 12:19:15 -0400 (EDT) In-Reply-To: (Eli Zaretskii's message of "Mon, 29 Sep 2008 17:36:53 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3113=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:104225 Archived-At: > That would work as well, but I'm not sure about the ``simpler'' part. It's definitely a simpler change, which means it's probably safer. > The code is already pretty convoluted, and I'm not sure why. All it > needs to do is (1) to find an existing parent directory of its > argument FILE by chopping directories from the end until it finds an > existing one, and (2) go up the tree of existing directories until it > finds one whose owner is different. This looks like 2 separate loops > to me, but the code for some reason insists on doing it in a single > loop. I think it's mostly a historical accident, but it's also so that both loops get the other's fixes. > How about this: > (defun locate-dominating-file (file regexp) > "Look up the directory hierarchy from FILE for a file matching REGEXP." > ;; If FILE does not exist, find its parent directory that does. > (or (file-exists-p file) > (while (and file (not (file-directory-p file))) > (setq file (file-name-directory (directory-file-name file))))) In some corner cases, this can infloop. That's why we do (if (equal dir (setq dir ...)) ...) test in the main loop. IIRC I wrote pretty much the above loop at some point and when faced with those issues I figured it was preferable to reuse the main loop so as to reuse all the experience it embodies. > And btw, won't the user test cover the case of crossing ~/ as well? In 99% of the cases, yes. > If so, we don't need to abbreviate-file-name, which then incurs > further overhead inside expand-file-name. This overhead should be negligible. Furthermore, I'm not sure whether we'll keep the user-test since it is incompatible with some (rare) usage patterns. Stefan