[Top][All Lists]

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

Re: find-file-project

From: Stephen Leake
Subject: Re: find-file-project
Date: Wed, 16 Sep 2015 11:58:00 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)

Dmitry Gutov <address@hidden> 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

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

-- Stephe

reply via email to

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