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 20:50:57 +0200 Message-ID: <5644DF91.2040503@yandex.ru> 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; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1447354279 16060 80.91.229.3 (12 Nov 2015 18:51:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 18:51:19 +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 19:51:11 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 1Zwwxg-0003tm-HE for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 19:51:08 +0100 Original-Received: from localhost ([::1]:49135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwwxg-0000zL-1z for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 13:51:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwwxb-0000wd-LE for emacs-devel@gnu.org; Thu, 12 Nov 2015 13:51:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwwxY-0001d1-Bb for emacs-devel@gnu.org; Thu, 12 Nov 2015 13:51:03 -0500 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:37480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwwxY-0001cd-6D for emacs-devel@gnu.org; Thu, 12 Nov 2015 13:51:00 -0500 Original-Received: by wmww144 with SMTP id w144so101727466wmw.0 for ; Thu, 12 Nov 2015 10:50:59 -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=quRHdPPndRanvHHYEnitbpzjsird0qh6CwGZ5jKpvVg=; b=UpBhosFrjPo68NpDi5R/k80hgnNL1xJxRRsRNI5wv/OkiZOoi0sA4JOUQ+QUvKssRA 1sU5Ppz6oCeG9dflFcUhUz50tPyucaxP7dekRvzMvqwKqvvA4H5n6HhVj/em8rE0vsDn Ssb7++Gqi0KjwhF4Bo3gPAaRErlfEdpuO3AoGu5/Txo6PHVok4Hwu7HvQjAE8OTtNU1y 6pDlnUxA7t02+MKAO4ESxspEiQc8HaxB9doMNViUsr6kIqGM9sS/m76U8FlKnXgIDpji j3tpUeQfpcGiBxGu4gbtaPSxDQ2Q9MgTMMju/tHNjeQl4BTZEFnEjlQUwLNyNuHbgR8o 1G2Q== X-Received: by 10.28.145.134 with SMTP id t128mr44556067wmd.64.1447354259571; Thu, 12 Nov 2015 10:50:59 -0800 (PST) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id 184sm16428371wmk.10.2015.11.12.10.50.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2015 10:50:58 -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::231 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:194272 Archived-At: On 11/12/2015 08:17 PM, John Wiegley wrote: > 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?" How can you ask the question about "this directory", if the code responding to the question doesn't know it's not allowed to use the contents of the current buffer? Aren't you bothered by the perspective of getting two different answers about the directory, depending on which file you're visiting? > 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. I meant more like having to M-x customize-variable for each backend I end up using. >> 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. Well, I'm going to wait for the specifics. But maybe you should consider using other APIs for those other things. I wouldn't call the API a "system". From where I'm standing, it should just be a set of contracts tailored for a particular purpose. There's no "inheritance" anywhere, so you can't really reuse it for highly different things. >> 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. The 25.1 release is months away, judging for the feature freeze lengths of previous Emacs releases. So I think we could make an exception for project.el, considering it's basically just words, and not a lot of code that might need exhaustive testing. But still, it's your decision. > 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. Yes on first two statements, but I'll have to see what the "defaults" will look like. > 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. Let's do that, then.