[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 15:09:09 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 |
On 08/01/2015 01:21 PM, Stephen Leake wrote:
I want to ensure the core project API does not prevent me from writing
the backends I want. It must also provide sufficient reason for me to
use it; the fewer features I need that it has, the less reason I have to
use it.
I think the API is sufficiently powerful for that already (flat vs
recursive is the main unresolved issue). As for features, hopefully the
list will grow, but many of them can come, eventually, from third-party
packages.
Is it a problem if they are present for others to use?
We are discussing a core Emacs feature that will be used by many people;
it cannot cater to only your personal opinions.
So far it's mostly you and me in this discussion. But there are existing
packages that implement project support for Emacs, and the ones I've
used (Projectile and Eproject) don't work like that either.
What you've described here, could be a separate project backend. One
you're welcome to write.
Any backend that supports project files will need functions like these;
project files are precisely centralized manual configuration.
Not at all, they need variables. You can easily set the variables from
.dir-locals.el, and any Emacs-wielding team member on the same project
will use them automatically.
So far I'm fuzzy on whether the variables should be global, or
project-vc specific. Probably the latter.
So they belong in the root class.
I'm pretty sure you expend a lot more effort on parsing any given kind
of project file, than storing ignores or search-path would take.
If I end up writing everything in the backend, there's no point in using
the "unified project interface".
It's an interface, like the "I" in API. Backends implement a set of
methods that other functions can use.
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/08/01
- Re: cl-defgeneric vs random funcall in project.el,
Dmitry Gutov <=
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/08/01
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/08/01
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/08/01
- Re: cl-defgeneric vs random funcall in project.el, João Távora, 2015/08/04
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/08/04
- Re: cl-defgeneric vs random funcall in project.el, João Távora, 2015/08/04
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/08/04
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/08/09
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/08/09
- Re: cl-defgeneric vs random funcall in project.el, João Távora, 2015/08/10