[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
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.
- Re: cl-defgeneric vs random funcall in project.el, (continued)
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/31
- Re: cl-defgeneric vs random funcall in project.el,
Dmitry Gutov <=
- Re: cl-defgeneric vs random funcall in project.el, Stefan Monnier, 2015/07/30