Re: project.el semantics

[Dmitry Gutov]

On 11/12/2015 07:26 PM, John Wiegley wrote:

> 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.

That's true, too.

> 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.

In *each* project backend, separately? And then I, as a user, will have 
to hunt down every such setting in every implementation, and change it?

> 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.

Why don't you provide some justification for flexibility? I did provide 
a justification for the given restriction.

> 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.

Again, I disagree, on this particular issue.

Too bad you haven't presented any alternative design, or examples of 
features that won't work in the current design.

And I'd really like to see what that "set of defaults" is going to look 
like.

> 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've asked for outside input on two particular questions. You haven't 
addressed the more interesting one, but decided that you want to do 
everything different, in an unspecified way.

That's fine, as long as you're going to take up responsibility for the 
feature now. And good luck with your vision.

Also note that, as far as the discussion with Stephen is concerned, we 
may be reaching some consensus here. But hey, you're the maintainer.

> 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.

I will agree to that, as long as you remove xref from the source tree, 
too. It has a number design questions unsolved, and I consider them much 
more important. While it works to an extent, the decisions in question 
will most likely severely change the data structures used, and I don't 
want to have to be tied by having to support the current data structures 
later.

So if you think we can't get project.el (a relatively small package) 
right in time for the release, we definitely won't be able to do that 
for xref.