all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Eric M. Ludlam" <eric@siege-engine.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>,
	 John Yates <john@yates-sheets.org>,
	emacs-devel@gnu.org, Jorgen Schaefer <forcer@forcix.cx>
Subject: Re: A unified project root interface
Date: Sat, 23 Mar 2013 13:10:20 -0400	[thread overview]
Message-ID: <514DE1FC.4020805@siege-engine.com> (raw)
In-Reply-To: <87li9fyy6v.fsf@engster.org>



On 03/22/2013 04:30 PM, David Engster wrote:
> Eric M. Ludlam writes:
>> On 03/21/2013 12:32 PM, David Engster wrote:
>>> And what would happen when `ede-check-for-vcs-dirs' returns t?  Would
>>> that load EDE then, or would we try to go on to provide the basic
>>> functionality (like getting the root) with a class-less version?
>>
>> I think this will be a bit of a challenge.  The project detection, and
>> then project hash are the key important pieces.  If the goal is to get
>> something that will be dumped w/ Emacs, and Fast, we'd need to start
>> by refactoring ede/files.el to split out the parts that track the
>> directory-to-project associations from all the misc EDE related file
>> finding routines.
>
> Frankly, I don't think this is the right approach. To cite from Jorgen's
> initial post which started this whole thread:
>
> "The usual way to define a project is via the "project root", a
> directory so that all files under that directory are considered part of
> "the project"."
>
> As he also stresses, this is *not* a complex problem to solve, quite the
> contrary.
>
> Therefore, I don't think it is necessary or even desirable to rewrite
> the whole EDE project autodetection into a class-less version, which
> then by all means tries to delay loading the "real" EDE as long as
> possible. It is not necessary that an 'emacs -Q' can detect all kinds of
> projects from Linux kernel trees to the Emacs source. If people need
> this, they should just put 'global-ede-mode' in their init file (which
> takes about 0.1 seconds on my machine) and use the full-fledged EDE.

To be plain, I agree.  What Jorgen described is not the EDE project 
loader.  Here's the deal though.  EDE's project loader was once what 
Jorgen described, without all the classes and stuff.  It just detected 
the project, found the root, and moved on.

Different projects need different features though, and things evolved. 
If a simple project system is put into Emacs core, it will satisfy the 
primary use case.  Then over time the case+1 will evolve it until it is 
just as messy as the EDE one.

Case:  simple.el is 6000+ lines of code.  Everything from set-variable 
(pretty simple) to compose-mail-other-frame (what ??).

If this project concept is created as a simple thing, that's fine, but 
EDE won't be able to use it, though it could contribute.   If that's the 
overall story where simple uses need the simple project, and EDE is used 
when you need more, that seems like a fine compromise, but it won't 
simplify the plethora of project projects.  Of course, that's a good 
thing too.

Eric



  reply	other threads:[~2013-03-23 17:10 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-09 16:44 A unified project root interface Jorgen Schaefer
2013-03-09 17:12 ` Fabian Ezequiel Gallina
2013-03-10  5:38 ` Stefan Monnier
2013-03-10 10:06   ` Jorgen Schaefer
2013-03-11 18:57   ` Lluís
2013-03-12 23:28     ` Eric M. Ludlam
2013-03-12 23:42       ` Jorgen Schaefer
2013-03-13  2:02         ` Eric M. Ludlam
2013-03-13 18:03       ` David Engster
2013-03-13 19:11         ` Sudish Joseph
2013-03-16  0:47         ` Eric M. Ludlam
2013-03-16 14:18           ` David Engster
2013-03-16 15:02             ` Jorgen Schaefer
2013-03-16 22:27               ` Phil Hagelberg
2013-03-16 22:59               ` David Engster
2013-03-16 23:16                 ` Jorgen Schaefer
2013-03-17 17:40                   ` David Engster
2013-03-17 18:18                     ` Jorgen Schaefer
2013-03-18 22:50                       ` David Engster
2013-03-19  1:57                         ` John Yates
2013-03-19  7:18                           ` David Engster
2013-03-19 12:23                             ` Eric M. Ludlam
2013-03-19 13:06                             ` Stefan Monnier
2013-03-19 19:09                               ` David Engster
2013-03-20  3:21                                 ` Stefan Monnier
2013-03-20  4:48                                   ` Leo Liu
2013-03-20  7:04                                     ` joakim
2013-03-20  7:05                                     ` David Engster
2013-03-20  7:13                                   ` David Engster
2013-03-20 12:57                                     ` Stefan Monnier
2013-03-20 16:14                                       ` Davis Herring
2013-03-20 17:41                                         ` Stefan Monnier
2013-03-20 17:48                                         ` Stefan Monnier
2013-03-20 18:20                                         ` Bruce Korb
2013-03-20 22:14                                           ` Stefan Monnier
2013-03-20 16:34                                       ` David Engster
2013-03-20 17:47                                         ` Stefan Monnier
2013-03-21  0:55                                           ` Eric M. Ludlam
2013-03-21  3:27                                             ` Stefan Monnier
2013-03-21  4:07                                               ` Eric M. Ludlam
2013-03-21 14:33                                                 ` Stefan Monnier
2013-03-22  2:12                                                 ` Eric M. Ludlam
2013-03-23 11:04                                                   ` EIEIO split (was: A unified project root interface) David Engster
2013-03-21 16:32                                             ` A unified project root interface David Engster
2013-03-22  0:47                                               ` Eric M. Ludlam
2013-03-22 20:30                                                 ` David Engster
2013-03-23 17:10                                                   ` Eric M. Ludlam [this message]
2013-03-23 17:26                                                     ` Jorgen Schaefer
2013-03-23 18:02                                                       ` Dmitry Gutov
2013-03-23 20:51                                                         ` Pascal J. Bourguignon
2013-03-24  4:25                                                           ` Dmitry Gutov
2013-03-24 10:13                                                             ` Jorgen Schaefer
2013-04-06 13:25                                                               ` Jorgen Schaefer
2013-04-06 17:13                                                                 ` Eric M. Ludlam
2013-04-08 19:03                                                                   ` David Engster
2013-12-31 20:12                                                               ` Daniel Colascione
2013-03-20 17:49                                         ` Jorgen Schaefer
2013-03-19  7:33                         ` Jorgen Schaefer
2013-03-17  8:08                 ` joakim
2013-03-12 15:34   ` Sudish Joseph
2013-03-12 16:51     ` Dmitry Gutov
2013-03-12 18:23   ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=514DE1FC.4020805@siege-engine.com \
    --to=eric@siege-engine.com \
    --cc=emacs-devel@gnu.org \
    --cc=forcer@forcix.cx \
    --cc=john@yates-sheets.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.