From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: project.el semantics Date: Thu, 12 Nov 2015 19:53:54 +0200 Message-ID: <5644D232.6020002@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> <86pp1ixem2.fsf@stephe-leake.org> <55FAFC36.5010506@yandex.ru> <86twqrww0u.fsf_-_@stephe-leake.org> <563EA9B9.5080404@yandex.ru> <86vb9dufs0.fsf@stephe-leake.org> <563F4915.1080008@yandex.ru> <867flrbksb.fsf@stephe-leake.org> <56409F2D.9060300@yandex.ru> <86mvun9gz7.fsf@stephe-leake.org> <56415902.90103@yandex.ru> <86h9ktah9x.fsf@stephe-leake.org> <56429025.3070008@yandex.ru> <86r3jw4yrf.fsf@stephe-leake.org> <564340DC.5020008@yandex.ru> <564374E7.50600@yandex.ru> <5643B749.8030600@yandex.ru> <5643F79F.9080103@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1447350866 21049 80.91.229.3 (12 Nov 2015 17:54:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 17:54:26 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 18:54:22 2015 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 1Zww4e-00061X-Qt for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 18:54:16 +0100 Original-Received: from localhost ([::1]:48531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zww4e-0001KK-7z for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 12:54:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33005) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zww4P-0000yO-EC for emacs-devel@gnu.org; Thu, 12 Nov 2015 12:54:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zww4M-00084U-73 for emacs-devel@gnu.org; Thu, 12 Nov 2015 12:54:01 -0500 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:37379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zww4M-000848-11 for emacs-devel@gnu.org; Thu, 12 Nov 2015 12:53:58 -0500 Original-Received: by wmww144 with SMTP id w144so99556206wmw.0 for ; Thu, 12 Nov 2015 09:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=3YVIegEhoPWWiB0e30/aXVYW5KY7cNjDjTJ/W5Vza7A=; b=d7D7XIvzyqgnrzk4TZX839JTncGbQhCZ275YZOlSO2weDqDKogPiL5oBl9lrZO54c9 oaybZkFurFIab80DSgFO5sa1cS1AkARPV3mb2hqK1vl2v2CXryCqz2hrId3jCxQU6XNN 7k52PpxVNQVbsd0244bo06lAj7q1MMPsKcGurL2wx7Op+T9d7ajZux0XGiGCJzCy016E C7Ay+tLkApVALoxuniBc5Lyed7RXKJ+jo3/l9QT4Tf1JSWOgkBpdD8iYS2Is2xskF7zI vcUu//nIJvR1lyuoqdUgcrnTGptLf4GnsHrSFA4SuXcGpazaSlb/OuDbSwGxQdIdJK97 HKCg== X-Received: by 10.28.129.131 with SMTP id c125mr41627810wmd.21.1447350837495; Thu, 12 Nov 2015 09:53:57 -0800 (PST) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id l81sm16212808wmb.2.2015.11.12.09.53.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2015 09:53:56 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22d 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:194262 Archived-At: On 11/12/2015 07:26 PM, John Wiegley wrote: > Simple in this case might also be misleading, since "libraries" has a very > particular connotation, whereas the functionality we're talking about could be > about so much more than libraries. That's true, too. > Yes, I do. This type of decision shouldn't be baked into the core API -- it > should be provided as a default configuration that *uses* that API. In *each* project backend, separately? And then I, as a user, will have to hunt down every such setting in every implementation, and change it? > I'm not opposed to what you want to achieve -- far from it. I just want to get > there a different way, which will leave open a wider road for future changes. Why don't you provide some justification for flexibility? I did provide a justification for the given restriction. > Right now, project.el is "baking in" a lot of decisions that I don't see as > necessary at that level. What I'm suggesting is a more general API, plus a set > of defaults, where the *end result* is likely to behave much like what you've > proposed. Again, I disagree, on this particular issue. Too bad you haven't presented any alternative design, or examples of features that won't work in the current design. And I'd really like to see what that "set of defaults" is going to look like. > I think we've reached the point where it is clear that project.el, as stated, > is not ready for inclusion in 25.1. I _really do_ want a module like this, I > just want something broader. This sort of module is key to my IDE vision, > which is why I care so much about getting this right. I've asked for outside input on two particular questions. You haven't addressed the more interesting one, but decided that you want to do everything different, in an unspecified way. That's fine, as long as you're going to take up responsibility for the feature now. And good luck with your vision. Also note that, as far as the discussion with Stephen is concerned, we may be reaching some consensus here. But hey, you're the maintainer. > I would like to remove project.el from the source tree for now, and move it to > a feature branch for further discussion and development. I understand this is > disappointing, but I'm fairly certain you'll be happier with where we end up > down the road. I intend the very same functionality you're proposing now, but > in a way that will allow many more cool things besides. I will agree to that, as long as you remove xref from the source tree, too. It has a number design questions unsolved, and I consider them much more important. While it works to an extent, the decisions in question will most likely severely change the data structures used, and I don't want to have to be tied by having to support the current data structures later. So if you think we can't get project.el (a relatively small package) right in time for the release, we definitely won't be able to do that for xref.