[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 22:54:30 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

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?

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.

reply via email to

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