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: Fri, 13 Nov 2015 00:04:11 +0200 Message-ID: <56450CDB.9050604@yandex.ru> 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> <86wptob2v6.fsf@stephe-leake.org> <5643CEAA.6000103@yandex.ru> <86si4bemyw.fsf@stephe-leake.org> <564478CA.20108@yandex.ru> <86y4e3c90y.fsf@stephe-leake.org> 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 1447365876 13079 80.91.229.3 (12 Nov 2015 22:04:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 22:04:36 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 23:04:36 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 1Zwzys-0008SG-9m for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 23:04:34 +0100 Original-Received: from localhost ([::1]:49953 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwzyr-0007aY-H3 for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 17:04:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwzyd-0007aR-G3 for emacs-devel@gnu.org; Thu, 12 Nov 2015 17:04:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwzya-0001vD-9Y for emacs-devel@gnu.org; Thu, 12 Nov 2015 17:04:19 -0500 Original-Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]:33226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwzya-0001v1-0l for emacs-devel@gnu.org; Thu, 12 Nov 2015 17:04:16 -0500 Original-Received: by wmec201 with SMTP id c201so55019549wme.0 for ; Thu, 12 Nov 2015 14:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=AMEzFc7YeUHfFwy3zxoMUQjnd8w8IduzK17WBIwD/9U=; b=Doh/5rC8G+qoKeYib9xG77CGjMCaCt8UCefPUKZ0aNK9z8chef3FPtYNUYqxxyTrFS UZLW9BiPq2/CSXiL7SeKYo68ME8e157smgKdaGejMpkdDw2QAuuld7OeOBnxYP6X8K4O Rc8y8Y9ijj8/Oe6CKmVDp9E7rMNWapBGSF1ipJVH0QA5KR3YIAwfeJwdlK7A36xRFcwn QVfrlRlMCbD+VI1juG9nvGELzR+IcH3bQEyqCdsoycR6CqGV3Loikx7kuK9bJ0g6b86d u8mFz/rgCCGIHWCQMlDxtFU0Rm7T3JiCH7wdBcPFo2qmGgJKhHZogv8wCrkMLH+GusZN s1jA== X-Received: by 10.28.104.197 with SMTP id d188mr9731269wmc.55.1447365854986; Thu, 12 Nov 2015 14:04:14 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id u17sm708157wmd.8.2015.11.12.14.04.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Nov 2015 14:04:13 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <86y4e3c90y.fsf@stephe-leake.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::233 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:194291 Archived-At: On 11/12/2015 09:28 PM, Stephen Leake wrote: > Why define that in the API? Let the user do whatever they want. Or that. I'm just saying that a project backend probably wouldn't be able to tell. > Clearly, read/write is a useful item. One way the user can set it is via > .dir-local. Yeah, maybe. > I'm assuming the "edited together" comment on `project-roots' implies > "don't edit" on `project-library-roots'. Thus project-roots is > read-write, and project-library-roots is read-only. "Don't edit when working on this project". > Note that I am not talking about OS level file permissions, but about > the logical use of those directories in the context of the project. Very well. >> Let's be realistic. I doubt most people are going to use arbitrary >> predicates and searches that only touch some of the library-roots, as >> well as some of project-roots but other others, often. So we can serve >> the simplest case first. > > I agree. But the simplest case is to always search all the directories > (ie project-root and project-library-root). You are allowing that, plus > one other case. I meant the simplest approach that still allows a certain distinctions, like the one we've discussed (read-only/read-write). > In other words, I also doubt most people will want to search only > project-roots or only project-library-roots. I do think that many users would find only searching project-roots useful in practice. And that's what IDEs do: when you "search in project", you search only the project root(s). Maybe several projects, if they're open at the same time (in the same "workspace"), but not inside the libraries. >> The API doesn't factor into it. > > That's bad; you should not be able to do something interactively that > you cannot do programmatically. This should be: > > (defun project-find-regexp (regexp &optional dir) > "Find all matches for REGEXP in the current project. > If DIR is non-nil (default prefix arg), search in that instead. > If DIR is \\[universal-argument], prompts for DIR." As you can see, you're still able to "do that programmatically". The modified project-find-regexp illustrates that, because it's an API consumer, not a part of it. > The prompt for dir should use completing-read on project-roots and > project-library-roots; project-ignores should not have to cope with dir > outside that list. I'd change this requirement as follows: search an arbitrary directory inside the project, but use the project-ignores value for the project root that it's inside. There would be some technical issues, such as handling "rooted" ignores with find-grep. > This can also be implemented via a predicate arg to project-find-regexp; > then project-find-regexp-dir can prompt for a directory and construct > the appropriate predicate. I don't really see the need for the word "predicate" to appear anywhere near its definition, thus far. > The code writes the predicate function, not the user. > > I'll just pick the "read-only" metadata for an example: > > -*- lexical-binding: t; -*- > > (let* ((read-only (completing-read "read-only?" '(t nil))) > (predicate > (lambda (dir) > (eq read-only (metadata-read-only (project-metadata project dir)))))) > (project-find-regexp regexp predicate)) > > This could be extended to include the rest of the defined metadata. The consumer doesn't need to construct a "formal" predicate function: just ask the project API for a list of dirs, and filter out ones you don't like, maybe using cl-loop. > Well, that's one choice. But I'd prefer the predicate in the API, so I > don't have to implement the same predicate-calling code in each > higher-level function. You can use cl-remove-if-not. > On the other hand, the user code can just as easily distinguish > project-roots from project-library-roots; so why is that in the API? What user code? Please remember that the user doesn't in general, write Elisp code. How would project-find-regexp distinguish them? > You can't have it both ways; project-roots and project-libarary-roots is > just one special predicate. You could say that. > Yes, we want to document those properties. That's why I'm pushing so > hard to find out what "project-root" means; I'm trying to find out what > properties of the project you actually care about. > > We seem to have settled on "read-only". Yes, but if we're going the more flexible route, I prefer the words like "libraries" and "dependencies". Using them, the user might make the choice about which directories are interesting for the current search. > Still, it illustrates the need for another predicate on the result; > that could also be in the API, or at the client level. The consumer can just as well filter the results using cl-remove-if-not. >> If we go the project-directory-metadata route, what other accessors >> will be left? You want to remove project-library-roots, right? > > Yes, and merge its content into project-roots. > >> Will project-roots retain its name? > > Yes, that's fine. Please feel free to submit a patch across these lines (adding project-metadata). It might be moot now, given that John decided to pull project.el from Emacs 25.1, but it could at least serve as a point of comparison for his project API proposal.