From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: project.el semantics Date: Wed, 11 Nov 2015 03:44:43 -0600 Message-ID: <86ziyk50qc.fsf@stephe-leake.org> 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> <5641412B.8080106@yandex.ru> <564145FC.5020905@yandex.ru> <5641634C.9000409@yandex.ru> <5641CCCB.6050206@yandex.ru> <86h9kt777c.fsf@stephe-leake.org> <5642924D.80304@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447235193 5923 80.91.229.3 (11 Nov 2015 09:46:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 09:46:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 10:46:16 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 1ZwRyd-0003BT-U5 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 10:46:04 +0100 Original-Received: from localhost ([::1]:38923 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwRyY-0005us-Dm for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 04:45:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwRxv-0005s8-D4 for emacs-devel@gnu.org; Wed, 11 Nov 2015 04:45:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwRxX-0006ne-Gg for emacs-devel@gnu.org; Wed, 11 Nov 2015 04:45:19 -0500 Original-Received: from gproxy6-pub.mail.unifiedlayer.com ([67.222.39.168]:41126) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZwRxX-0006nJ-AL for emacs-devel@gnu.org; Wed, 11 Nov 2015 04:44:55 -0500 Original-Received: (qmail 21381 invoked by uid 0); 11 Nov 2015 09:44:52 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 11 Nov 2015 09:44:52 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id g9kn1r00A2UdiVW019kqkD; Wed, 11 Nov 2015 02:44:51 -0700 X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=qtqOOiqGOCEA:10 a=vaJtXVxTAAAA:8 a=WzMJ9s6KIXmhEMGeBS8A:9 Original-Received: from [76.218.37.33] (port=57360 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZwRxQ-0005HU-77; Wed, 11 Nov 2015 02:44:48 -0700 In-Reply-To: <5642924D.80304@yandex.ru> (Dmitry Gutov's message of "Wed, 11 Nov 2015 02:56:45 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.39.168 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:194043 Archived-At: Dmitry Gutov writes: > On 11/11/2015 01:41 AM, Stephen Leake wrote: > >> More precisely, the only hot issue is the semantics of >> "package-library-roots" and "package-roots". >> ... >> I don't understand why we have both; one would be sufficient. I have yet >> to see an actual use case that requires both. > > How could I explain that better? I want to: > > - Search inside the project root(s). But not inside libraries. > > - But sometimes inside libraries as well. > > Because usually libraries will only bring false positives. But for > some kinda of searches, searching in libraries proves insightful as > well. > > That's missing in this description? There is also the notion of "editable" vs "non-editable", in the doc string for project-roots. This doesn't tell me whether a dependency that is not a "library" belongs in project-root or project-library-root. But my main problem with this is that it is far too limiting. There are many other possible use cases for restricting a search over the list of directories related to a project: - Search in all dependencies that come from Google (or some other vendor). - Search only in directories that are not read-only. - Search only in directories that are not marked "passed unit testing". - Search only in directories that are not marked "refactoring for feature 'foo' finished". - etc. We cannot possibly anticipate the set of restrictions some user might want to put on a search. So why should we assume "search on libraries" is so important that it needs this level of attention? I think the correct approach is to add a "predicate" argument to functions that use the project directory path; similar to the "predicate" argument in completion tables. Then the user can supply a predicate function that implements each of the above use cases. -- -- Stephe