[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: Stephen Leake
Subject: Re: cl-defgeneric vs random funcall in project.el
Date: Thu, 30 Jul 2015 02:04:57 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)

Dmitry Gutov <address@hidden> writes:

> On 07/29/2015 05:24 PM, Stephen Leake wrote:
>>> """
>>> 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'.
>>> """
>> That means the _code_ for default method for the function
>> project-search-path should not append the value of the result of the
>> function project-root-directories.
> It was my mistake, then. I hope, though, after rereading that message,
> you can agree that it was an easy one to make.
>> The point was I thought that project-search-path and project-directories
>> were distinct concepts, not related to each other. The contents may
>> overlap, or either one may not be defined.
> Try to imagine the consequences of project-search-path having to
> include project-roots, or even some directories within them.
> Take emacs-lisp-mode, it makes project-search-path return load-path,
> through project-search-path-function.

Yes; that's exactly what it should do.

> Now, take an actual project implementation, like the one returned by
> project-try-vc. It doesn't know anything particular about Elisp, but
> there might be some directories with Elisp code inside the current
> project tree. There's no guarantee that they're added to load-path, at
> any given time. Should the VC project provide its own implementation
> of project-search-path?

If the "vc project backend" wants to be a "real project backend", then
yes, it needs to define project-search-path.

That would not be useful for editing elisp files; the elisp project
backend is useful for that.

Which is why elisp-mode sets the elisp project backend to be active.

I don't see the problem.

>> Now that I see that you intended them to mean project-path-read-only and
>> project-path-read-write, things have changed.
> These are pretty bad names, though.

Why? they give the precise meaning. What names would you propose?

-- Stephe

reply via email to

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