From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: project.el semantics Date: Thu, 12 Nov 2015 10:17:43 -0800 Message-ID: References: <86pp1j4ejm.fsf@stephe-leake.org> <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> <5644D232.6020002@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447352318 13727 80.91.229.3 (12 Nov 2015 18:18:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 18:18:38 +0000 (UTC) Cc: Stephen Leake , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 19:18:37 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 1ZwwRv-00005w-MA for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 19:18:19 +0100 Original-Received: from localhost ([::1]:48929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwwRv-0003oH-2V for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 13:18:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwwRX-0003l4-FU for emacs-devel@gnu.org; Thu, 12 Nov 2015 13:18:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwwRS-0000AH-Ft for emacs-devel@gnu.org; Thu, 12 Nov 2015 13:17:55 -0500 Original-Received: from mail-pa0-x236.google.com ([2607:f8b0:400e:c03::236]:35352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwwRS-0000AC-8I for emacs-devel@gnu.org; Thu, 12 Nov 2015 13:17:50 -0500 Original-Received: by pasz6 with SMTP id z6so74570048pas.2 for ; Thu, 12 Nov 2015 10:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version:content-type; bh=5cP5DX1knN7BqsZYr6t4XdUwmvJ1OsxGWZ09trc9G9E=; b=siCbkLMeFlW2wJ/Y+4f775ZWUw7Jr0h9fVzjpgTo+4BlW7Yg/tdkfamujL0eUnMYyE dL70BWtzM22vDsGBXkGwSN3d9EJ0E6OcB3DCyIQhqmcz2FNNrHgxaVNp7ClbeAx+csCr Jl1MtQbZ7w984ysKiUsooavNtrZOuhHYggv1YHd6/K1AAznsQwuAiVbkvCZQ7GKtmW8e Th8ctAWNnwA5d1CSnByd6rxaEvy4I7POC3eg+HY+gzFsqljwVRV01hNiQKAR2GiseET+ f8/wY7TKXLEzTWcILKX5h2J6sB/4TFyLtSkqEG5ngbfVfNbyP21EwPv55a04lpPDvl2n j0EQ== X-Received: by 10.66.121.110 with SMTP id lj14mr24724990pab.61.1447352269304; Thu, 12 Nov 2015 10:17:49 -0800 (PST) Original-Received: from Vulcan.attlocal.net (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id sy5sm4504163pac.5.2015.11.12.10.17.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Nov 2015 10:17:47 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.attlocal.net (Postfix, from userid 501) id 06AF8105774AB; Thu, 12 Nov 2015 10:17:47 -0800 (PST) In-Reply-To: <5644D232.6020002@yandex.ru> (Dmitry Gutov's message of "Thu, 12 Nov 2015 19:53:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: Dmitry Gutov , Stephen Leake , emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::236 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:194269 Archived-At: >>>>> Dmitry Gutov writes: > 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 think the average user shouldn't even know this machinery exists, the defaults should be so well chosen. We'll have a surface API for asking typical questions like "What files should be ignored in this directory?" Only advanced users should write any Lisp code; and they will be rewarded with the ability to configure the system to their heart's content. > Why don't you provide some justification for flexibility? I did provide a > justification for the given restriction. Because I want to use this system for things outside of those restrictions. > 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. This will take significantly more work than I can do in the time I have today. Proving to you that the alternative design is better will require me to write some of it, and that will need several days to work out at the very least. > That's fine, as long as you're going to take up responsibility for the > feature now. And good luck with your vision. Thanks, Dmitry, although I sense more frustration than congratulation in your wish... I certainly hope you will continue to work with me on this feature, since I'd like you to be in charge of the defaults, since in that area, your restrictions are most likely the right ones. To be clear: I'm not saying I don't like your vision. I just want your vision to be built on top of a broader foundation than it currently is. Your idea addresses the needn of multi-directory projects relying on external supporting libraries -- I want an API for talking about entity aggregation in general (buffers, files, directories, and other resources). Within such an API, projects and their supporting libraries should be a natural fit. > 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. That's quite acceptable. I'm not in a hurry, and want to get these new APIs right. > Or alternatively, we keep the new commands, as well as elisp and etags > implementations, but document them briefly, and declare the extension > interface (currently, xref-find-function), to be > private/experimental/work-in-progress. Also perfectly fine, whichever you think is best for xref.el. I'm OK with "trial features" appearing in a release, so long as we note that they may change without notice and shouldn't be too much relied upon. John