[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
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.
- Re: find-file-project, (continued)
- Re: find-file-project, Dmitry Gutov, 2015/09/17
- project.el semantics, Stephen Leake, 2015/09/18
- Re: project.el semantics, Dmitry Gutov, 2015/09/18
- Re: find-file-project, Dmitry Gutov, 2015/09/16
- Re: find-file-project, Stefan Monnier, 2015/09/16
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Dmitry Gutov, 2015/09/16
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project,
Dmitry Gutov <=
- project.el semantics, Stephen Leake, 2015/09/18
- Re: project.el semantics, Dmitry Gutov, 2015/09/18
- Re: project.el semantics, Stephen Leake, 2015/09/19
- Re: project.el semantics, Dmitry Gutov, 2015/09/19
- Re: find-file-project, Dmitry Gutov, 2015/09/16
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Dmitry Gutov, 2015/09/17
- Re: find-file-project, Stefan Monnier, 2015/09/16
- Re: find-file-project, Dmitry Gutov, 2015/09/17
- Re: find-file-project, Stefan Monnier, 2015/09/18