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: Wed, 11 Nov 2015 14:30:38 -0800 Message-ID: References: <86pp1j4ejm.fsf@stephe-leake.org> <86mvwmz58h.fsf@stephe-leake.org> <55F9A5F8.1030505@yandex.ru> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447281151 8073 80.91.229.3 (11 Nov 2015 22:32:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 22:32:31 +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 Wed Nov 11 23:32:25 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 1ZwdwG-0005fB-8W for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 23:32:24 +0100 Original-Received: from localhost ([::1]:43357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwdwF-0007uS-Jo for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 17:32:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwdvU-0007lz-Kf for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:32:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwdue-0006sq-Ld for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:31:36 -0500 Original-Received: from mail-pa0-x234.google.com ([2607:f8b0:400e:c03::234]:34678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwdue-0006sd-Ff for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:30:44 -0500 Original-Received: by padhx2 with SMTP id hx2so43228328pad.1 for ; Wed, 11 Nov 2015 14:30:44 -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=vLuIaqwMML9TmsyO/4B+chuUxfyiRwMLJAF5H1Ji19g=; b=X7y7vnmm2osfKlcdOyZ1Pe3WjAz3NWMYtE3oiBOmw0VfzQ//1lmX2/OVDdZOaiFjpr r+aqYHiK9qTRl2HilHxpMMAZqZEFWMT1PdA6bRxdukpMDb6I6s6363RblLSA+Svhu5vU mUnH9D6kpdKLMW07LmVinCSAQZXNnnFrhAj7b0RC1yKNjAG6TlG4PT2eALwZdlcoxZw6 BZadJMEL0PhzpuNs+ExKauxCPYhzh38+VlX3gjZXShIfV5mPA9f8E8iDNJ+oKVlTXNtX o0JMR5zegnDsXdS5XXwZQ8jxpTOi75t/OVrp6YzAnhxsG3yd7n2zPfxoonn9eMSC5dvn b4rg== X-Received: by 10.69.0.69 with SMTP id aw5mr18154575pbd.19.1447281043632; Wed, 11 Nov 2015 14:30:43 -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 ej2sm11156837pbc.26.2015.11.11.14.30.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Nov 2015 14:30:42 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.attlocal.net (Postfix, from userid 501) id 6E14D10561951; Wed, 11 Nov 2015 14:30:41 -0800 (PST) In-Reply-To: <5643B749.8030600@yandex.ru> (Dmitry Gutov's message of "Wed, 11 Nov 2015 23:46:49 +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::234 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:194165 Archived-At: >>>>> Dmitry Gutov writes: > I meant "external to the project" instead of "outside the project", of > course. What is the difference between these two? To my ears, they mean exactly the same thing. > Do you really think "project-ancillary-roots" is better than > "project-library-roots"? Neither sounds good, actually. I think we're too focused on "projects" having to do with code, where code uses libraries. A "library-root" presumes things about the content of the project which I suggest we don't need to presume. The filesets idea was not meant to complicate the API, but to step back and reassess the API we really want. I understand now why you chose "root" as a suffix, and that much makes sense. Here's where I'm coming from: When I'm sitting at a buffer in Emacs, that buffer is usually related to something. It could be just a buffer (like *scratch*) with no relation at all, but that's pretty rare. Typically, the only relationship it has is to a file. But it may have other relationships: - To other buffers - To other files - To other directories - To other directories trees The selection of these "other" things can be based on many, many different criteria: same file type, same directory, same "project" in the version control sense, same modification day, etc., etc. Why confine ourselves to thinking about code projects that use libraries, when we can imagine a larger picture, where the original idea is just a particular set of choices? I'd love to have a programmatic API for associating files and buffers, and a set of commands able to take these associations into account. I'd use them for lots of things that have nothing to do with source code. When I'm editing a Markdown file, for example, I might have a preview buffer showing me a PNG of the rendered result. These buffers are all related to my current "project", and I'd like a way to "save all files in project", or "close all buffers in project". Projectile gives me some of that today, but it's very much tied to Git and filesystem searching -- which are great default backends for this type of functionality, mind you; they just shouldn't be the limit of our thinking. This is one of the "IDE features" I mentioned several weeks ago, which is why I want us to spend more time thinking about it. Why start out with a smaller API that does a very focused thing, when we can imagine something much more capable? John