Re: progmodes/project.el and search paths

[Eric Ludlam]

On 08/02/2015 01:17 PM, Dmitry Gutov wrote:
> If you can propose better ways to do the same things, or something 
> else worth adding, please do. 

AND

On 08/04/2015 09:43 AM, Eli Zaretskii wrote:
> I really think we could benefit from presenting some kind of goal or
> vision for the project.el development.  AFAICS, it started as a way to
> standardize finding a "project root", then moved to finding "project
> directories", but now it seems we are discussing a much wider scope,
> something like infrastructure for project definition and possibly also
> IDEs?  If it's the latter, then I won't expect to see arguments about
> "complications outweighing benefits" in reference to features that are
> basic for any IDE that is worth its menus.
>
> So maybe we should step back a notch and decide anew where is
> project.el going, and what is and isn't in its scope?

Hi Dmitry,

I was tempted to start replying to multiple sub-threads in multiple 
emails, but I suspect there is nuance I am not expressing well, so I've 
opted to go back to one of your original questions to engage in a more 
positive way.

I scraped through some old threads, old code, and my memory to put 
together the attached org file.  The intent is to answer your first 
question about things worth adding to a generic project.  It also 
happens to be something that can answer Eli's question, so I quoted him too.

When the generic project was first proposed, I thought it was a good 
idea where either EDE could be adapted to be a base, or EDE could adapt 
to a new base.  I wasn't too picky, but I clearly had many assumptions 
about what it was that did not match.

EDE's story is one where it started out specific, but became more 
generic because I needed to provide services to external tools I was 
writing, and there was just a lot of code donations and demand for more 
project definitions.

Emacs has a lot of tools that could use a project service, and sometimes 
all the tool needs is a small push of convenience, and not full project 
management system.  A generic project system will make it easy to add 
small conveniences in lots of places you may not expect because tool 
authors will feel safe using it.

The attached is my experience of things I either needed in EDE's base 
classes to implement a project, or that some tool needed, and what I 
learned along the way.  You might think it is too EDE specific, but I 
put in only the most basic stuff, and put in things I kind of wish I had 
time to add to EDE.

I am sure there are entries you consider out of scope.  In my mind 
projects need a centralizing force to bring consistency in the same way 
comint brought some very basic consistency to shell buffers.  We should 
not skimp in approaching this goal.

I consider this file incomplete, but I hope it proves useful as a 
starting point.  I'd be happy to periodically update it for a little 
while if it is useful.

Eric

generic_project.txt
Description: Text document