From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Project systems (again) Date: Fri, 18 Apr 2014 00:58:54 -0700 Message-ID: <5350DB3E.3030803@dancol.org> References: <53504D2C.7070504@dancol.org> <83y4z3gn3n.fsf@gnu.org> <5350CF28.9010702@dancol.org> <83tx9rgjpo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1OS504IV7LtAESvxgcaCHPOs5FndOiXfb" X-Trace: ger.gmane.org 1397807956 30969 80.91.229.3 (18 Apr 2014 07:59:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Apr 2014 07:59:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 18 09:59:10 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wb3hS-0004mV-Ob for ged-emacs-devel@m.gmane.org; Fri, 18 Apr 2014 09:59:06 +0200 Original-Received: from localhost ([::1]:36791 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wb3hS-000494-Bk for ged-emacs-devel@m.gmane.org; Fri, 18 Apr 2014 03:59:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50563) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wb3hP-00048w-8a for emacs-devel@gnu.org; Fri, 18 Apr 2014 03:59:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wb3hO-0007bP-3r for emacs-devel@gnu.org; Fri, 18 Apr 2014 03:59:03 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:44343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wb3hI-0007a9-Ij; Fri, 18 Apr 2014 03:58:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=F/jETf50ujtTeniInN244er17GotO5+qwtiWsNSWAyw=; b=YUVrpk4JlQgnC6FH4hhAjT6z+68TWo5psHQyPwVvImz4GHwIK8SFRPS2+4XQh94utCfR2mG8SHX+1puONyQbzCusjb4WmAjaiPF602Ep1ftDuoWaQOEPJ5/jAQI+PulGLTRwzwXPNXJkQT8Lh9dtWbZraaZOT7XUSAOTr9sp8nBcM1lQGh+luZPD98+VGIb14M1uJnEmFqFywumI13vevyqabOjDhXxA1R62TGHt+vzK/1Hvoo9G9O251wDZ9+Ns4LGfHcPbm8LbWOoR03PnqI9kejB91QRFPGJA4pmWUTHgKY18GHJGYoiYYsVv7CM9ihYBfdG7ucb9n3Ai2HIZ5w==; Original-Received: from [2601:8:b200:2b6::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Wb3hH-0007aK-Kk; Fri, 18 Apr 2014 00:58:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <83tx9rgjpo.fsf@gnu.org> X-Enigmail-Version: 1.6 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171484 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1OS504IV7LtAESvxgcaCHPOs5FndOiXfb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/18/2014 12:50 AM, Eli Zaretskii wrote: >> Date: Fri, 18 Apr 2014 00:07:20 -0700 >> From: Daniel Colascione >> CC: emacs-devel@gnu.org >> >>> FWIW, I'd prefer that you work with EDE developers to improve and >>> extend what they have; >> >> If EIEIO can't be preloaded (or, equivalent morally, autoloaded on >> find-file), there's no point in pursuing EDE improvements. An EIEIO-le= ss >> EDE would be an EDE rewrite anyway. >=20 > I don't know enough about this: why couldn't EIEIO be autoloaded? Stefan was against it the last time this issue came up. There are namespace cleanliness issues as well as deeper issues of functional appropriateness. >> Plus, I don't think the problem space really warrants a complex >> object system: conventional elisp idioms are adequate. >=20 > Since EDE is already there, I think this is a moot point. (I believe > Eric explained why this design was chosen a while ago.) It's there, but it hasn't seen wide use. The existence of non-EDE projects like Projectile should tell us that EDE, as it stands today, isn't well-suited to being a default project system. >>> starting from scratch (or almost from scratch) >>> sounds like waste of effort, especially since some of the EDE is >>> already in Emacs.=20 >> >> I really don't want to start from scratch, but I think it's the best >> option. A project system is one of those systems for which the hard pa= rt >> isn't the coding, but agreeing on having a single interface to the cod= e. >> I think we need something much simpler than what exists. >=20 > Then how about asking the EDE developers to provide an "easy-ede" > layer which would conceal the complexity for those situations where > the corresponding power is not needed? That's what I'm proposing, except that I imagine EDE can sit on top of that layer, not that that layer could sit on top of EDE. >> I find the abstractions in EDE to be much more confusing than they are= >> useful. For something that, at its core, ought to be very simple, ther= e >> are too many concepts --- target, project, sub-project, config, projec= t >> placeholder, too much shared state, and too few opportunities for ad-h= oc >> customization. The system feels specialized for a project based on >> nested autoconf files that build C and C++, and the documentation >> reflects that. I understand that EDE started simple and grew >> functionality, but this functionality belongs in separate layers, not >> mingled into the core. >=20 > I see your point. However, EDE was added to Emacs with the intent > that it serves as basis for developing features such as what you have > in mind. If there's a reasonably practical way of basing your project > on EDE, I think we should explore that possibility first, even if it > requires more work on the EDE infrastructure side, because not doing > so would waste the effort of integrating EDE into Emacs. I was afraid of an argument of this form --- it's just the sunken costs fallacy, isn't it? The fact that effort has been put into EDE shouldn't influence our evaluations of present alternatives. I don't think using EDE as a base would reduce the amount of needed work. I actually think it would increase it. --1OS504IV7LtAESvxgcaCHPOs5FndOiXfb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTUNs+AAoJEMAaIROpHW7Ip80P/17idWA8eonuJ5S/SGUJFJ7l v7R6GIUorCqgCdvSDJjdah0LhViOBW/xwDZISaoc8FYN8fT8tmyhMju8B1DjQKvM uwxUBX+nP7SG3xuZr2Vth1TfkM0oHUf+MS42lclMc8baoILxjSJjLhSZj67SpCWE Zr3dxstUgO8kTGq/PW3eDOEK0vGk/B1jloTxKYPDvLN+/oaIExkLy92PltIOsQcP zX8DwnjCTd3eFs9I8BH/XjTd4o12V4SstVYvfjNTXy9ROVZe14/+FFrUJqBarum4 p3bzKOO5hXgXuoJ25meNn3uo7arLTGa/cYJnqYfDmYFxqJeEnmpTbZFAIcqSDyWP ZbhMqCdz+HSStRgsTz45Ht+/ixXGuQ89nEdJfEEyV+Ku4T+OJA9BtYWOq2RYCZtO vTF7NfOGmnnS6TQ6YmUE42F/OFQamzPBEr1tfGM/+DPNviQWgt7rwWyBbLE80eY4 bxbkXecAVE3kA94nWqFH9PcrxQL9BuM9C1JHtdHJiXmbh/JTJlI2n2aAE0ppDL9e pE6ZpJrwKbymbpnY0O/PljQ70KXO8Sxpgvyop5nrHnT/6v1WavCQW2J8rvixQ3E2 wSpie0NztBv4dacKk9I9YgDoALZs8HfAMvDTgIC4pjir4SLc2dSo2/5sM6rkjdcO RSS9udQDVli1raLW7wnB =y3I0 -----END PGP SIGNATURE----- --1OS504IV7LtAESvxgcaCHPOs5FndOiXfb--