[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: find-file-project

From: Dmitry Gutov
Subject: Re: find-file-project
Date: Thu, 17 Sep 2015 20:15:55 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]