Re: project.el semantics

[Dmitry Gutov <dgutov@yandex.ru>]

On 11/12/2015 12:14 AM, Stephen Leake wrote:

> Ok, I can see the need for some sort of metadata. But that suggests:
>
> (cl-defgeneric project-metadata (project dir)
> "Return interesting metadata for DIR in PROJECT."
> ...)

Yes, more or less. Instead of directories, we could have complex objects 
like John suggests, with their own properties, but the above seems be 
simpler.

> We need more examples of useful metadata before we can begin to design a
> format for the return result.

Probably. I just have in mind one tag so far, e.g. let's call it 
"category". There might be none (in which case the directory is a part 
of the project), it might be "library", and/or something else.

> Used to; I'm retired now.

That's a pretty good job as well. :)

>> Then project-roots will contain dscovr, sal and common. And
>> library-roots will have what's left in the search path (Ada runtime
>> library).
>
> You did not answer the most important part of the question: "why?".

Because, from dscovr depends on sal and common, and according to your 
description, the person working on dscovr can make changes to sal and 
common as well, if needed. So a search across "current project, as well 
as code I edit together with it" would include dscovr, sal and common.

Which sounds useful to me, but I don't really know your workflows. If 
the dscovr developer doesn't need to edit sal and common 98% of their 
time, maybe they should indeed go into project-library-roots.

If they only need to edit sal or common for like 5-20% of their work on 
dscovr, maybe a finer distinction is needed, like three kinds of searches:

- Across project-roots and project-library-roots.

- project-roots only.

- The one project roots the current buffer is in.

Which complicates things a bit, but it's still simpler than having user 
predicates and arbitrary metadata.

> I'm left with "in order to decide which directories go in project-root
> vs project-library-root, ask Dmitry".

Everybody should Ask Dmitry more often.

>> Personally, I expect that to be useful (e.g. limiting searches to the
>> projects that you control). But if not, you an also disregard that
>> distinction. Do you see any downsides to it?
>
> Yes; it's not flexible enough. There were times when I wanted to search
> only in map/, or only in sal/. I just used grep-find.

You can also use C-u M-x project-find-regexp, and point it to map/ or 
sal/. Specifying a single directory is relatively easy anyway.

> I could only dream about the other use cases I described, but they did
> come up. For refactoring, I would make a low-level change, that would
> generate lots of compiler errors (Ada is a big help here). Then I would
> maintain a manual list of which ones were fixed in a text file.

I save test errors log from the Compilation buffer to file too, from 
time to time.

> Some more structured system would be nice.

I think a harder question would be, how do you want the list to be 
updated. Apparently you don't want to just recompile the whole project, 
or you wouldn't need the text file.

>> I'm hoping that you can still distinguish sal and common from the
>> standard library somehow, programmatically.
>
> Only by knowing the directory layout of the disk; the Ada project
> doesn't care, so it doesn't know.

If all else fails, they could be tagged with a directory-local variable, 
via .dir-locals.el. That would also give the choice of "is this library 
or not" to the user.

> Right. On the other hand, a user-defined predicate would be a
> reasonable feature for xref-find-references.

It might be.

> The predicate can query the metadata, via project-metadata.

I can display all available metadata to the user, and ask: directories 
with which pieces of metadata set do you want to search? The user enters 
the category names, separated by spaces, and the search proceeds.

I can't do the same with predicates. I can't even list them all, really.

> We have to agree that the UI is a separate discussion, or we will get nowhere.

The API should take possible UIs into account. Like described above, if 
we standardize on metadata, I can imagine at least one UI. If we 
standardize on arbitrary predicates, it's much harder.

This kind of change to the API should even come with a corresponding 
change proposal for xref-find-references, to demonstrate that it's viable.