[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: Sat, 1 Aug 2015 01:52:46 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

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

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.

reply via email to

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