Re: project.el semantics

[Dmitry Gutov]

On 11/12/2015 08:17 PM, John Wiegley wrote:

> 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?"

How can you ask the question about "this directory", if the code 
responding to the question doesn't know it's not allowed to use the 
contents of the current buffer? Aren't you bothered by the perspective 
of getting two different answers about the directory, depending on which 
file you're visiting?

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

I meant more like having to M-x customize-variable for each backend I 
end up using.

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

Well, I'm going to wait for the specifics.

But maybe you should consider using other APIs for those other things.

I wouldn't call the API a "system". From where I'm standing, it should 
just be a set of contracts tailored for a particular purpose. There's no 
"inheritance" anywhere, so you can't really reuse it for highly 
different things.

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

The 25.1 release is months away, judging for the feature freeze lengths 
of previous Emacs releases. So I think we could make an exception for 
project.el, considering it's basically just words, and not a lot of code 
that might need exhaustive testing.

But still, it's your decision.

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

Yes on first two statements, but I'll have to see what the "defaults" 
will look like.

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

Let's do that, then.