Re: progmodes/project.el and search paths

[Dmitry Gutov <dgutov@yandex.ru>]

On 08/12/2015 03:49 AM, Eric Ludlam wrote:

> Every project is indeed different.  A system that needs to load lisp
> code needs to protect against ill formatted lisp code.  Putting this in
> a core system will help implementations from all creating the same
> latent bug.  If project.el isn't going to provide detection services,
> then it won't need this feature.

Probably not, at least not at first.

> In EDE, a project adds itself to the list of possible projects. Each
> project classifies itself by a term that places itself in one of three
> bins, and hopefully those bins don't conflict. ;)

Not to dismiss the detailed approach, but the user could reorder the 
elements in project-find-functions as well, if the default order is not 
to their liking.

What you're describing would be an improvement, but not of the 
revolutionary kind. And I'm not really sure how to fit the 
classification together with project-find-functions.

> Right.  Each project implementation needs to update their data from the
> file system their own way.  If there are generic development menus, it
> would be helpful for the user to have one way to update project meta
> data regardless of which type of implementation is active.

I'd rather user never had to do that at all.

>> * "Project Local Variables" look very similar to project metadata.
>
> They are a type of meta data that let users provide extended behavior to
> the project.

That sounds fine in theory, but we need a more concrete application. 
Your Projectile example, for instance, would work just as well if it 
didn't set the "project local variables" via the project API, and just 
stored the information in its internal storage.

> I will need to look at your search path concept more.  Are there
> multiple paths for different purposes?

No, just this one. Adding other paths will need more justification.

> Several of these tools have an 'update the current tags file' type mode
> you can get at.  I don't recall if I wrapped that up with a handy
> function or not.

That would be nice. But then you don't need any extra information about 
the current project to do that, just knowing how to find the file and/or 
call the tool.

In that case, it shouldn't need anything new in the project API. Not 
even how to find the root, maybe (just use locate-dominating-file, 
especially when there are several tags files in the project).

> The key concept is that a project is rarely just one single activity.
> Usually there are doc activities, code activities, build system
> activities.  Some projects have Java activities, and native C++
> activities.  All these different things are for a common goal, and often
> there is a common lingo between them.  I represent that lingo as 'tags'
> in Semantic, and it enables you to 'copy' a tag which includes the meta
> data around the name and 'paste' it into a buffer of a different
> language.

That sounds like it needs a parser to work well. xref tries to handle it 
as "identifier at point", but we'll have to see whether the different 
implementations will include context information in it (via text 
properties).

> The only useful one there can turn a lisp tag into a texi
> @defun block, but you could imagine a way to update your java native
> methods bidirectionally.   The project knows how to link these systems
> together, such as finding the right doc for your Lisp code.

For one thing, writing documentation separately from sources is an alien 
idea to me (and for other Ruby, Java or JS programmers, I think). So 
this kind of information may need to be exposed as an optional service.

> Language specificity was key for me because of the way mode-local works,
> and how each language had customized behavior for the parsing tools.  I
> tended to focus on language specific accurate behaviors, and not generic
> potentially inaccurate features.  For example, smart completion vs
> dabbrevs.

I like smart completion, but by tying it to projects we'd discount the 
less accurate implementations that are still useful. On the other hand, 
a package that implements project handling can add its own, accurate 
completion functions as well.

> As noted somewhere, symref had a way of converting modes to patterns.  I
> had to ask around, but eventually got something pretty good.

It didn't work well for Ruby files initially, so I had to add the 
respective entries to semantic-symref-filepattern-alist. I'm sure there 
are languages out there that are still not covered.

> I'd be glad if I could stop maintaining parts of EDE because it became
> part of some core system.   It is still unclear to me where the
> boundaries lie.  I'm not sure where a patch would be helpful yet.  My
> hope is that my document would help you define the bounds of project.el
> based in a set of terms we can both agree to.  It would then be obvious
> how I could help by donating pieces of EDE as needed.

My understanding of EDE is if there are tools that would be worth 
porting, they would need to be rewritten on top of more general methods, 
and would probably need rethinking.

> My recommendation for you is to perhaps not reply to individual
> clarifications above, but perhaps define where you think project.el fits
> into the whole using whatever you like from my doc, and that would help
> us focus the conversation on the boundary, and not on random things I
> invented that aren't close to the boundary.

I'll try to do something like that in the foreseeable future. But 
really, from where I'm standing, the question is not how to decide the 
list of features, but how to implement each particular feature in a way 
that would make sense for as many project types as possible.