[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: Re: cl-defgeneric vs random funcall in project.el
Date: Wed, 29 Jul 2015 04:19:08 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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'.

reply via email to

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