Re: project.el semantics

[John Wiegley <jwiegley@gmail.com>]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> 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 think the average user shouldn't even know this machinery exists, the
defaults should be so well chosen. We'll have a surface API for asking typical
questions like "What files should be ignored in this directory?" Only advanced
users should write any Lisp code; and they will be rewarded with the ability
to configure the system to their heart's content.

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

Because I want to use this system for things outside of those restrictions.

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

This will take significantly more work than I can do in the time I have today.
Proving to you that the alternative design is better will require me to write
some of it, and that will need several days to work out at the very least.

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

Thanks, Dmitry, although I sense more frustration than congratulation in your
wish... I certainly hope you will continue to work with me on this feature,
since I'd like you to be in charge of the defaults, since in that area, your
restrictions are most likely the right ones.

To be clear: I'm not saying I don't like your vision. I just want your vision
to be built on top of a broader foundation than it currently is. Your idea
addresses the needn of multi-directory projects relying on external supporting
libraries -- I want an API for talking about entity aggregation in general
(buffers, files, directories, and other resources). Within such an API,
projects and their supporting libraries should be a natural fit.

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

That's quite acceptable. I'm not in a hurry, and want to get these new APIs
right.

> Or alternatively, we keep the new commands, as well as elisp and etags
> implementations, but document them briefly, and declare the extension
> interface (currently, xref-find-function), to be
> private/experimental/work-in-progress.

Also perfectly fine, whichever you think is best for xref.el. I'm OK with
"trial features" appearing in a release, so long as we note that they may
change without notice and shouldn't be too much relied upon.

John