Re: Per-language project-search-path, was: Re: Unified project interface

[Dmitry Gutov]

Hi Erc,

On 08/02/2015 05:29 AM, Eric Ludlam wrote:

> EDE does not have a list of 'find' type functions.  Instead, each
> project type declares a small structure with functions for identifying
> the dominating file, which classes to implement, and for some complex

"which classes to implement" - what does that mean? Is this something 
interesting, in the context of this discussion?

> EDE was not originally intended to be a way to search for files, but
> this feature was needed for semantic to find headers and referenced
> files using short names.

I think it's quite natural for a project to be able to list the 
directories where related files could be found. For instance, so that 
someone could implement a find-file-in-project command. Or search across 
those files.

> It does this with 'ede-expand-filename'. For
> projects that include an exhaustive list of files as part of the
> configuration (such as Automake) searches just go through the known
> files using major-mode to filter if needed.

This seems useful enough, although maybe I'd untie the expand-filename 
logic from a given project implementation and make it dependent on the 
major mode. For instance, no matter if it's a common Java project or an 
Android project, whether it's based on Ant, or Maven, or Gradle, the 
logic for finding the file based on the class name is the same: you just 
need the list of directories to look in.

Which project-search-path might correspond to.

> For particularly large projects with a lot of source files, you can bind
> in an external tools such as Global or locate to help you find files
> when the basics don't work out.

Global seems fine to search inside the project (for certain languages, 
at least), but what about the system libraries? Headers, etc. If they're 
used in the current project, being able to search in them would be 
useful, too.

> EDE had to manage the concept of derived modes via the mode-local tool
> in order to handle cases where C++ was like C with a few more details.
> If you intend to dispatch behavior based on mode, I strongly recommend
> mode local as a way to make it declarative and traceable.

That's interesting, but it doesn't sidestep the issue of different users 
possibly using alternative major modes for the same files.

So far as I see it, in most cases the project implementation could 
easily write something ad-hoc like that that would be good enough. IOW, 
I'm more concerned about the basics right now.

> ede-source-paths is implemented for several java flavors, such as
> ant/maven and android.  It is then used by semantic's javap database
> backend, and SRecode's template based code generator.

I see, thank you. I've only been looking in CEDET inside Emacs.

> It works well for java because class names and path names line up
> nicely.  It hasn't been used for anything else, even though the comment
> mentions C++.

In Ruby, class and module names also often map to file paths. Only by 
convention, though, so there's some variability there. The same happens, 
to certain degrees, in other languages too.

> I suspect what your source-paths concept better matches EDE's targets
> concept.  EDE breaks a project into targets, matching a Makefile style
> target if that metadata is available.  Each target represents some set
> of source files, usually all of the same mode.

Maybe? I'm not sure how the concept of targets maps to dynamic 
languages, for example.

> EDE also tracks include paths, which are locations where you might
> include code from some other location, matching the C/C++ concept. It
> works ok for some other languages, but primarily it is for that. Java
> has it's own classpath notion to better match what it does.

Indeed. project-search-path, as it's currently imagined, is a merge of 
ede-source-paths and ede-system-include-path.

So xref-find-regexp and xref-find-references will, by default, search 
the includes path too. Something that symref doesn't do.

> > Any reason why symref isn't using it?
>
> Symref style searching, which I assume is like your xref concept,
> doesn't line up with the various paths in EDE, as EDE doesn't really
> need those types of paths for anything.  Even the semantic tool, which
> used to deal with lists of project roots dropped the concept in favor of
> EDE's project detection as it was superior for all use cases.

Yes, we also try to reuse semantic-symref-find-references-by-name in the 
default implementation of xref-find-references.

The two main drawbacks now are: it doesn't handle the project's ignored 
directories (which should be relevant for symref/grep.el), and 
semantic-symref-filepattern-alist needs to have correct entries for 
every language.

> Every EDE project marks the top directory of a source tree, with
> .ede-ignore enabling breaks for nested projects.  Using that top path,
> you can use find/grep, GNU Global, and various other tools to do your
> searching for you.  The nice thing when you start using Global or CScope
> is that your config for the tool in question does the mode type
> filtering for you.

I suppose. As long as the tool supports all kinds of operators (search 
for references, regexp, listing files), and supports your target 
language. Though it probably won't help with related code outside of 
your project's tree anyway.

Maybe xref-find-references should also always search all project-roots 
anyway (while filtering by file names and ignoring non-interesting 
directories), and project-search-path should focus on "source roots" 
(inside and outside of the project tree) exclusively. So even if the 
project has a build file written in the same language as the rest of it 
(and it lies in the root directory), project-search-path still would 
only include, say, project/lib and project/app.

The main use case for those entries, then, would be locating the file 
for a given class name. Which could serve as a basis for a naive 
find-definition implementation.

> My experience with EDE and other CEDET pieces is that I need to do
> symref type searches quite rarely.  Usually the various tag based
> searches do a fine job getting me the data I need, the exception being
> finding uses of some function.

"Finding uses" is an operation I have to do quite frequently.

> I had intended symref to be where
> various refactoring tools would be based, as it allows you to select
> various hits, and perform operations on only selected hits.

Yup, support for renaming is something I'm interested in as well. It's 
generally accepted that Emacs's refactoring support is lacking/nonexistent.