Re: find-file-project

[Dmitry Gutov]

On 09/16/2015 07:58 PM, Stephen Leake wrote:

> > It's not an Ada project.
>
> That's not a useful definition, and therefore not helpful in moving this
> discussion towards closure.

It's fairly workable, though, as I think we've established.

We could call a project "flat" if, to create a source file in a new 
directory to the program, it's always necessary to add the new directory 
to a build file as well, or to some "directory paths" variable in the 
program's environment.

That doesn't hold true for Emacs Lisp because we can add a file in a 
foo/bar, when only foo is in load-path, and then (require 'foo/bar) 
somewhere.

By that measure, many Makefile-based projects could be called flat. So 
if we take just the part of Emacs written in C, if we add a new dir 
under src/, we'll have to modify Makefile with its settings.

But no one really expects to ever have directories under src/ containing 
irrelevant files. And since we want to be able to visit src/bitmaps/* 
anyway (don't we?), we might as well treat src/ in a recursive fashion 
anyway.

So I rather call a project "flat" if, in addition to the condition 
above, treating its directory list in a recursive fashion leads to 
results surprising to the user.

> > search-path may have entries where one is a subdirectory of another,
> > but each such entry is "recursive" anyway (we have to consider all
> > files inside each respective tree).
>
> That's clearly suboptimal; the subdirectory will be processed twice in
> every use of project-search-path. Why would that ever be a good idea?

Currently, the default implementation of project-search-path calls 
project-prune-directories. We could require it of all implementations, 
so that there's no duplication of this kind.

But then we won't be able to search for "qualified file names", like 
"semantic/symref/cscope.el" (or would do it less accurately). Which 
might be important in "jump to an import" usages. Not in Elisp (we have 
a better implementation of that already), but in other languages.

So maybe a better approach is to allow project-search-path to include 
both "emacs/lisp" and "emacs/lisp/progmodes", and either ask callers to 
use project-prune-directories as needed, or provide an accessor that 
returns the path already pruned (project-search-path-roots?).

> It clearly complicates completion; we have to delete lots of actual
> duplicates, rather than only worrying about files in different
> directories having the same name.

project-prune-directories is a fairly quick function. Compared to a 
serious operation like listing files, it has no performance hit. 
(project-prune-directories load-path) takes 2ms here.

What's so complicated?

> When would such a definition of project-search-path actually be useful?
>
> You are going a long way merely to justify calling "load-path" recursive.

Whether I justify it or not, semantic/symref/cscope.el isn't going 
anywhere. *And* it's even more useful in other languages, like Ruby or Java.

> > I don't see that. If you need this complexity, just use the
> > "recursive" format (it's more powerful),
>
> It is not "more powerful"; we have already agreed that one format can be
> converted accurately to the other; the code in the patch implements those
> conversions.

In theory, probably. But the format of "flat" ignores you've proposed is 
less powerful than the current project-ignores.

Or is project-ignore-files-globs supposed to contain items like 
"foo/*.c"? Or "foo/*/", or "foo/*/bar"?

> You are missing my main point; the user must specify information in
> addition to "load-path" in order to determine the correct search path
> for an elisp project.

I don't think we really can avoid that. Your definition of the Elisp 
project will fail in some project we don't know about that also uses 
nesting and the format (require 'foo/bar/tee).

> Whether that additional information is specified as "extra includes" or
> "extra ignores" is a secondary issue.

One also has to look at the actual language they're working with.

> Yes, that is the user intent. The question is, how is the user supposed
> to specify that intent to the elisp project? "load-path" alone does not
> state whether it should be ignored; the user must provide additional
> information.

And now you've hardcoded the same information in the project definition. 
Which will work most of the time, and then it'll fail for someone, for 
the reason described above.

You could argue that "most of the time" is good enough, but note that 
the cogre problem you're trying to solve is pretty niche as well. I may 
never encounter any similar problems with Elisp.

And adding a single ignore is pretty easy.