Re: find-file-project

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09/16/2015 05:13 PM, Stephen Leake wrote:
>
>>>> And this is ridiculous. Emacs obviously isn't a "flat" project.
>>>
>>> I don't know what you mean by "a flat project".
>
> It's not an Ada project.

That's not a useful definition, and therefore not helpful in moving this
discussion towards closure.

>>> load-path is neither purely flat (cedet requires recursion) nor purely
>>> recursive (it has both emacs/lisp and emacs/lisp/progmodes etc). So it
>>> has to be converted one way or another.
>
> "emacs/lisp and emacs/lisp/progmodes" is not a good counter-argument.
>
> 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?

project-prune-directories optimizes that usage, so that
project-seach-path is purely recursive; I assume that's why it's there.
project-recursive-ignores-to-flat does the same conversion, more
accurately (it also produces the ignores list).

> When search path used for file traversal, the caller will simply have
> to filter out the entries that are redundant for its purposes.

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.

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.

>> And the user has to provide additional information as to what parts are
>> flat vs recursive, for the conversion to be done properly.
>
> 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. 


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.

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

>> For example, SourceForge CEDET contains the "cogre" directory under
>> "cedet". Since that is not part of Emacs core yet, if I'm testing
>> SourceForge Emacs prior to a merge with Emacs core, it is not
>> appropriate to include "cogre" in the project search path.
>
> Well, ignore it, then.

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.

-- 
-- Stephe