Re: project.el semantics

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 11/10/2015 07:36 PM, Stephen Leake wrote:
>
>>> 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.
>
> So I'm not adding it. Just keeping that possibility in mind, and hence
> keeping the word "dependency" free.

My point is you don't have a good use case for "library", either. At
least, the use case for "search only on libraries" is no more important
than other similar "search only on ..." use cases.

>> 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.
>
> How would they provide the predicate when calling the command
> interactively? Especially a predicate that would distinguish between
> project roots and library roots.

In a lot of cases, they will simply search the entire directory list,
and filter the results manually as they go thru them.

But they can take the time to write a predicate function, and invoke the
command via M-; to supply it as an argument in the call.

Or they could write a wrapper that provides a list of common predicates.

In general, project.el is not about the final user interface, it is
about providing core functionality.

>>> 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".
>
> That implies the (not (member ...)) semantics, rather than (not
> (file-in-directory-p ...)), which is what
> `project-subtract-directories' actually does.

Since project-roots is treated recursively, "not included in" means (not
(file-in-directory-p ...)) to me.

> And "not member" semantics seems pointless to me here; we might as
> well allow project-library-roots to include project-roots element, if
> the consumer will have to call `project-combine-directories' on them
> together.

I'm confused. With the current definitions, project-roots and
project-library-roots are disjoint, so the user does have to call
project-combine-directories if they want to search on both.

You now seem to be agreeing with me; it would be better to have only
one project-roots function.

> Having "library roots" entirely outside the project roots, however,
> makes a lot of sense to me intuitively: if they're inside, they are a
> part of the project anyway. What kind of use would we have for such
> elements?

I'm not sure what you are asking here.

You seem to be asking "why would we want to search on
project-library-roots". But obviously you _do_ want the ability to
search on that; that's why it's there. So I must be missing something.

>>> 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.
>
> Would you be able to give an example of a project file that lists
> dependencies like that, that "should be edited together" with the
> current project? It would fit the manual well.

We have not defined an Emacs project file yet. I can easily provide an
Ada example, but I don't think you want that actual file in the Emacs
manual.

Any case where a large project is divided into subprojects, all of which
are editable. For example, my NASA GDS projects looked like this:

GDS
    sal

    common

    map

    dscovr

All four of these are projects. "sal" and "common" are lower level; they
are used by "map" and "dscovr", which are the projects used by the MAP
and DSCOVR missions respectively (you can Google those ...). "sal" and
"common" are listed as dependencies in the "map" and "dscovr" Ada
project files. Nothing in "map" depends on "dscovr", and vice-versa.

All of them depend on the Ada runtime library, which is also in the
project search path.

All of them are maintained by the GDS team. There is one GDS team member
primarily responsible for each mission-level project; I was mostly
responsible for the common projects. Any GDS team member can edit any
file in any project.

The only thing that is a "library" is the Ada runtime library, installed
with the Ada compiler.

So for the dscovr project, what goes in project-roots, and what goes in
project-library-roots, and why?

Note that the Ada project tool provides only one "source search path";
it does not distinguish between "libraries" and "non-libraries". For the
dscovr project, "dscovr", "sal", "common", and the runtime library are
in the search path.

>> I could write a new global xref backend, but it's better to reuse
>> existing code.
>
> Does lisp/cedet/cedet-global.el have code that will help us with
> implementing "find definitions" using Global?

Yes. I've started an implementation that does that:

(defun semantic-symref--xref-find-definitions (symbol &optional symref-tool)
  "Implement `xref-find-function' for 'definitions for the semantic/symref 
backend.
SYMREF-TOOL determines which symref tool to use (default
'detect); see `semantic-symref-tool-alist'."
  (require 'semantic/symref)
  (defvar semantic-symref-tool)
  (let* ((semantic-symref-tool (or symref-tool 'detect))
         (res (semantic-symref-find-tags-by-name symbol 'project))
         (hits (and res (oref res hit-lines)))
         xrefs)

    (dolist (hit hits)
      (push
       (xref-file-location
        :file (cdr hit)
        :line (car hit)
        :column 0)
       ;; FIXME: add :hint (match-string 3))
       xrefs))

    xrefs))

>>> 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?
>
> We have both project-find-regexp and project-or-libraries-find-regexp
> already, and I find the difference between them useful in practice.

Yes, sorry, I temporarily forgot about those; they are new.

xref-find-references needs similar treatment to be consistent. But I
think that's the wrong approach; adding a more general user-specified
predicate function is much better.

-- 
-- Stephe