[Top][All Lists]

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

Re: {Spam?} Re: progmodes/project.el and search paths

From: David Engster
Subject: Re: {Spam?} Re: progmodes/project.el and search paths
Date: Fri, 07 Aug 2015 13:43:56 +0200
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4 (gnu/linux)

Eric Ludlam writes:
> On 08/06/2015 07:10 PM, Stefan Monnier wrote:
>>> It would be nice if the generic base project were the same.  Any project
>>> backend you use would have similar keybindings, menus, detection mechanisms,
>>> file location systems, etc because it will be easier to use the base support
>>> than invent something new.
>> Could be nice, but I think it's a different beast from project.el.
>> I actually have the impression that what you describe already exists and
>> is called EDE ;-)
> Hmmm.   Now I'm back to the beginning of the thread.
> Perhaps project.el is really project-root.el.  I think that would
> clarify a lot, and would continue to be helpful to the tools that only
> need to know about the root.  A clear intent would prevent
> misconceptions from causing the base to grow into something
> unintended.

Despite what may have been said, project.el is *not* meant to be some
kind of "base class" for different project systems (that was at least
what I initially thought, and which you seem to think as well). The way
I see it, project.el is more like an adapter, although one that
delegates the actual implementation, so something like an "abstract
adapter". Dmitry and Stefan are saying that this adapter should only
provide the information that is common to all possible project systems,
which pretty much means "the list of files/directories that are part of
this project". While I agree this will already be very useful, as it
allows you to use xref, grep, ido-find-file, etc. on the current
project. I also think this is a very small feature for claiming the
whole project- namespace.

> I'm also interested in how to resolve some of the misconceptions about
> EDE.  Perhaps looking at what prevents it from being 'on by default',

Last time we discussed this it boiled down to "we cannot preload EIEIO".


reply via email to

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