Re: cl-defgeneric vs random funcall in project.el

[Dmitry Gutov <dgutov@yandex.ru>]

On 07/29/2015 04:00 AM, Stephen Leake wrote:

> Why would it use 'cl-call-next-method'? That would call the
> default method, which is wrong; that's why we're overriding it.

A project-specific implementation could call cl-call-next-method, to 
find out what the major mode thinks the search-path should be.

> Nothing else in project.el currently suggests that
> 'project-search-path-function' should be a list; the default method for
> project-search-path doesn't treat it as a list. What is the use case
> for this? I remember seeing something in the email chain; did that get
> captured somewhere?

The value is not a list. It's a function, which could take different 
values in different modes. If a project implementation is concerned with 
different languages, it could obtain the value of this variable 
corresponding to all major modes (using temporary buffers, for instance; 
or the author could just hardcode the list), then call those functions, 
and append them together.

>> However, now that we've reached the consensus that project-search-path
>> doesn't need to include the directories inside the current project,
>
> I never agreed to that. In fact, I thought the only thing we _did_ agree
> on was that project-search-path included the main project. Sigh.

Seriously? Here's a quote from one of your messages:

"""
So some specific change proposals:

- Rename 'project-directories' to 'project-root-directories' or
   'project-roots'. The current project root should always be first in
   the list.

- 'project-search-path' should not include 'project-root-directories'.
"""