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

[Dmitry Gutov <dgutov@yandex.ru>]

On 07/31/2015 05:36 PM, Stephen Leake wrote:

> It would help to be more specific. Since we disagree, you can't assume
> I'll guess what you have in mind; my first response was "so why would
> you want to?". To be truly persuasive, you need to anticipate that
> response, and address it before it happens.

I'm sorry, I think I've addressed that question in one (or several) 
previous messages. I'm not a native speaker, and simply writing that the 
first time takes a sizable amount of effort. Repeating, and rephrasing, 
and reiterating, adds to that.

Further, I wasn't sure which aspect of the question you wanted 
addressed: the question was "which functionality", not "why". The 
assumption was that you're already clear on the latter.

To sum up: false negative results (not finding a valid occurrence of a 
given symbol) are much worse than false positives (finding a false 
occurrence of the given symbol, for instance, finding words in README 
when looking for a Java method). So it's better when our default 
behavior, with zero configuration performed by the user (maybe yet, or 
maybe they're not going to configure anything further at all), leans 
toward false positives rather than false negatives.

For those reasons, I've left the current implementation of 
project-search-path largely intact in the recent commit. If the 
backend-specialized implementation has no extra information (the user 
hasn't performed any relevant configuration), then project-search-path 
includes entire project-roots.

> A concrete example directory structure:
> ...
> The user has set load-path to (".../myproj/lisp" "~/.emacs.d/elpa/..."
> ".../emacs-25.0/share/..." ...)

Maybe they didn't, but even if they did...

> One search the user might want to do: find the name of an elisp function
> in a test driver script file, to see how it is tested, while
> simultaneously finding all places that function is used in the *.el
> files, to review the test cases to ensure they are sufficient.

Indeed. It's a common operation.

> It would be wrong to add the entire directory tree that contains .git;
> the user is using emacs 25, so they don't want to see the emacs 24.3
> files. Obviously, there is a separate case where they do want to see
> those files; that's a different project configuration.

It's really impractical, IMO, to have different project configurations 
for different use cases. A fancy project backend could have those, 
though, and the user would be able to switch to their heart's content. 
We are not discussing a fancy project backend here, though.

To be clear, here are the two main "separate cases": navigating to all 
definitions, and aliases for different Emacs versions; navigating to all 
references to a given function, again, in code for different Emacs 
versions (to be able to rename them, for instance). As a project 
maintainer, I want all of those visible and on the tips of my fingers, 
because I need to maintain all code. Not just the code currently loaded 
in my Emacs.

> We could provide:
>
> (defun project-create (root)
> ...
> `project-root-alist' associates root directories with project objects;
> ...
> (defun project-add-search-path (project path)
> ...
> (defun project-add-search-ignore (project ignores)

Sorry, this is too much a centralized, manual configuration for my 
taste. The VC project backend is simple, and requires minimal 
intervention from the user. We could add some variables (to be set via 
.dir-locals.el), but I don't want to have to add anything to my init.el 
as soon as I start working on a new project. For one thing, my .emacs.d 
is published on GitHub, for all to see.

What you've described here, could be a separate project backend. One 
you're welcome to write.

> Then, in the same place they add myproj/lisp to load-path, the user
> adds:

Again, in all likelihood they don't do that anywhere. As a real example, 
I have a few small Elisp one-file packages, the Git checkouts of which 
are never in load-path.

During the (infrequent) bouts of their development, I evaluate the whole 
buffer, write the changes, test them interactively, then commit and 
push. Then wait a while while MELPA builds the new version, and upgrade 
the installed one via M-x list-packages U RET.