[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: project.el semantics

From: Dmitry Gutov
Subject: Re: project.el semantics
Date: Thu, 12 Nov 2015 19:53:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0

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

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.

reply via email to

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