Re: project.el semantics

[John Wiegley]

>>>>> Dmitry Gutov <address@hidden> writes:

> "Project libraries" paint a quick and simple picture. Which, I imagine,
> might be good for the first adopters of the API. I'm not going to hold on
> tight to it, but please keep in mind that simple is often good.

Simple in this case might also be misleading, since "libraries" has a very
particular connotation, whereas the functionality we're talking about could be
about so much more than libraries.

> project-find-functions being explicitly documented to depend only on the
> directory, but not on the contents of the current buffer, is a conscious
> decision: I don't want to see foo.el belong to one project, and README.md
> lying nearby in the same dir, to another, from the standpoint of this API.
> Do you disagree?

Yes, I do. This type of decision shouldn't be baked into the core API -- it
should be provided as a default configuration that *uses* that API.

I'm not opposed to what you want to achieve -- far from it. I just want to get
there a different way, which will leave open a wider road for future changes.
Right now, project.el is "baking in" a lot of decisions that I don't see as
necessary at that level. What I'm suggesting is a more general API, plus a set
of defaults, where the *end result* is likely to behave much like what you've
proposed.

> I don't really see the end result from your description. Judging from just
> that message, you either want to remove project-library-roots and add a
> bunch of some other accessors instead, or remove all current cl-defgeneric
> declarations and declare each project to be a hash-table, using some sets of
> keys, both predefined (?) and not, and documented to have files and
> directories as values. The first option is simply vague, the second one,
> well, writing code for it would definitely be more error-prone: currently,
> if you mistype the name of a generic function, at least you get a warning.
> 
> You'll have to give more specifics either way.

I think we've reached the point where it is clear that project.el, as stated,
is not ready for inclusion in 25.1. I _really do_ want a module like this, I
just want something broader. This sort of module is key to my IDE vision,
which is why I care so much about getting this right.

I would like to remove project.el from the source tree for now, and move it to
a feature branch for further discussion and development. I understand this is
disappointing, but I'm fairly certain you'll be happier with where we end up
down the road. I intend the very same functionality you're proposing now, but
in a way that will allow many more cool things besides.

John