emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: progmodes/project.el and search paths


From: Eric Ludlam
Subject: Re: progmodes/project.el and search paths
Date: Tue, 04 Aug 2015 21:29:19 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

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

Attachment: generic_project.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]