Re: locate-dominating-file calls `stat' too eagerly

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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