[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 01:26:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0

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

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.

reply via email to

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