[Top][All Lists]

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

Re: progmodes/project.el and search paths

From: Dmitry Gutov
Subject: Re: progmodes/project.el and search paths
Date: Sun, 2 Aug 2015 20:17:15 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

Hi Eric,

On 08/02/2015 04:52 PM, Eric Ludlam wrote:

project.el and the current discussion seems to revolve almost entirely
around search paths and xref.  EDE does project management, but has not
needed to track search paths the way project.el does.  It certainly has
ways to find files, and has include paths and such needed by source
code, but not generic search paths.  I think project.el should be recast
as defining search paths for search tools.  EDE could then plug itself
in to provide some paths if asked.  I think calling it a "project" is
overstating what project.el does.

The intention is to provide a generic API that other packages can use. The roots and search-path looked to be the most important things to know about a project, so far.

If you can propose better ways to do the same things, or something else worth adding, please do.

In the meantime, attached is a small patch to enable EDE to provide
roots to project.el.  The new function works for me with 24.3, but I
didn't try it in project.el

I've implemented EDE support similarly to your patch initially, but then Stefan opined it's better to dispatch on the actual EIEIO class. This implementation lives near the bottom of ede.el in Emacs master. Please take a look and try it sometime.

Perhaps all the work you're doing could just hang off ede since it only
takes 2 lines of code, and if it is missing some sort of pruning tricks,
it could just be added to ede.

project.el defines a generic API. EDE is one implementation.

One that a lot of Emacs users still avoid using (hard to tell exactly why; probably because it doesn't match every kind of project). Projectile seems to the most popular "project implementation" out there.

Anyway, the suggestion to replace an agnostic API with a specific implementation doesn't make a lot of sense.

reply via email to

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