Re: project.el semantics

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

>> You can easily get the project from the directory, and you can easily
>> search the directory. So the directory is more useful.
>
> I don't know about that. If you only know the directory, you're at the
> mercy of project-find-functions. If (project-dependencies project)
> returns project instances, however, you're free to choose the right
> project implementation to use for them, set up "parent project"
> references, use some other information from the current project file,
> and so on.
>
> Although again, what will the project dependencies be used for, is
> still an open question for me.

The general rule is: if we don't have a good use case, don't add code.

>> I don't see the point of making that distinction here; the files in
>> non-editable places will be read-only. Non-edit does not imply
>> non-search.
>
> In dynamic languages that I've used, the library files are often
> perfectly editable. You just don't want to do that, most of the time.
>
> Another thing you might want to do - replace some term across the
> project (using M-x project-find-regexp and then M-x
> xref-query-replace). If we were to show its occurrences in library
> files as well, that would be a waste of user's and computer's time.

You can't allow for all possible user desires by providing different
path functions at this level.

Instead, there should just be one path, that includes all files that the
user might want to do anything with. Then, when the user actually
invokes a function to do something, they can provide a predicate if they
want a subset of that.

>>> I'm using "outside" as "directory terminology".
>>
>> So what would be wrong with including both ways of describing it, so
>> more people understand what is wanted?
>
> I generally try to get away with using as little words as possible
> when describing something, because words can be misunderstood,
> especially new ones, which haven't been used before in the given
> context (such as "dependency").

"outside" is a new word in that sense.

You have to rely on common definitions; "dependency" is one (although
apparently not for you, sigh).

"outside" is a common English word, but "outside the project" is very
fuzzy. 

> Since we're discussing project-library-roots here, I'm not sure which
> improvement you mean. How about simply replacing "the list of
> directories outside of the project" with "the list of directories
> outside of the project roots"?

I suggest "not included in" rather than "outside".

> Because if we describe it in terms of dependencies, a dependency might
> be checked out inside a project root subdirectory in certain
> configurations (maybe with an appropriate .gitignore entry, maybe
> not). In that case, though, we probably don't want to have
> project-library-roots include it.

Why not? We allow subdirectories in the same path in general (ie
`load-path'); that's what project-prune-directories is for.

> We can add "So if the project has dependencies which should be edited
> together with it, they should go here as well." to the third paragraph
> of the project-roots docstring. 

That would be good.

>> So provide alternate wording that uses the concepts "separate projects"
>> and "dependencies", and says what you want it to say.
>>
>> People will want to know.
>
> Guess that might go into the manual instead. I've seen someone state
> that it's okay for the manual to have redundancies.

Ok, please start the manual. That would help a lot.

>> Right; so project-find-references should be a cl-defgeneric.
>
> Keep in mind that the current Grep-based "find references" are sloppy,
> best-effort implementations. It's not like we expect the users to use
> them when there's any other alternative.

Right; that's what default implementations of generic functions are for.

>> xref-collect-references would be better named
>> xref-semantic-find-references; it is a semantic implementation of
>> xref-find-references.
>
> It's a... semantic-symref-tool implementation of it, actually. Which
> has no relation to Semantic grammars, its tags, or etc.

Ok, so xref-semantic-symref-find-references, or
xref-symref-find-references. 

> And I'm seriously considering to get away from it and always use Grep,
> because the other tools, while they can be faster, they're also
> entirely opaque to the user, can have outdated databases, non-indexed
> relevant directories, unsupported languages, and so on.

But if I normally use global, I want xref to use it. And I know how to
deal with all those issues. Although some details in the manual would
help. 

I could write a new global xref backend, but it's better to reuse
existing code.

Unless you are proposing to rewrite symref to be more consistent with
xref. 

>> It's simpler to avoid the whole issue and merge project-roots and
>> project-library-roots, at least in this first iteration of the project
>> API. Then we can find out if people actually want a choice of paths.
>
> IMO, it's more important to have the distinction between "project
> roots" and "project library roots" in "find regexp" than in "find
> references".

But you don't provide any code that allows the user to take advantage of
that distinction. So it how important can it be?

>>> Where I come from, it's common enough to have several "project files",
>>> so to speak, at the top of a project, coming from different languages.
>>> For instance, having both Gemfile and package.json.
>>
>> I would merge multiple project files into one Emacs project, not have
>> different Emacs projects for each language.
>
> And to do that, vc-project needs to know how to get library-roots from
> each of those project files. From a hook. Right?

No, I would not expect vc-project to know anything about project files.

I would write a new project backend that knows about some set of project
files. 

-- 
-- Stephe