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: Thu, 12 Nov 2015 00:44:07 -0600 Message-ID: <86si4bemyw.fsf@stephe-leake.org> References: <86pp1j4ejm.fsf@stephe-leake.org> <86bnd21q0r.fsf@stephe-leake.org> <55F97EA2.9000408@yandex.ru> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447310694 18445 80.91.229.3 (12 Nov 2015 06:44:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 06:44:54 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 07:44:42 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 1Zwlcb-0005ce-B5 for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 07:44:37 +0100 Original-Received: from localhost ([::1]:44831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwlca-0008Cq-K5 for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 01:44:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwlcN-0008Cl-G7 for emacs-devel@gnu.org; Thu, 12 Nov 2015 01:44:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwlcI-0004JW-F9 for emacs-devel@gnu.org; Thu, 12 Nov 2015 01:44:23 -0500 Original-Received: from gproxy7-pub.mail.unifiedlayer.com ([70.40.196.235]:34295) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZwlcI-0004I9-7g for emacs-devel@gnu.org; Thu, 12 Nov 2015 01:44:18 -0500 Original-Received: (qmail 27066 invoked by uid 0); 12 Nov 2015 06:44:13 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 12 Nov 2015 06:44:13 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id gWkA1r00E2UdiVW01WkDXx; Wed, 11 Nov 2015 23:44:13 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa 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=sJxngOyaPTiyDKJ5LR4A:9 Original-Received: from [76.218.37.33] (port=49774 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZwlcA-00077j-2X; Wed, 11 Nov 2015 23:44:10 -0700 In-Reply-To: <5643CEAA.6000103@yandex.ru> (Dmitry Gutov's message of "Thu, 12 Nov 2015 01:26:34 +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: 70.40.196.235 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:194193 Archived-At: Dmitry Gutov writes: > On 11/12/2015 12:14 AM, Stephen Leake wrote: > >> Ok, I can see the need for some sort of metadata. But that suggests: >> >> (cl-defgeneric project-metadata (project dir) >> "Return interesting metadata for DIR in PROJECT." >> ...) > > Yes, more or less. Instead of directories, we could have complex > objects like John suggests, with their own properties, but the above > seems be simpler. > >> We need more examples of useful metadata before we can begin to design a >> format for the return result. > > Probably. I just have in mind one tag so far, e.g. let's call it > "category". There might be none (in which case the directory is a part > of the project), If I pass in a DIR that is _not_ related to the project, the category should be something like "unknown". So we have at least four values for category: unknown top-level (ie "the project") library other-dependency But then there is also, orthogonal to category: editable (or read-write) read-only >>> Then project-roots will contain dscovr, sal and common. And >>> library-roots will have what's left in the search path (Ada runtime >>> library). >> >> You did not answer the most important part of the question: "why?". > > Because, from dscovr depends on sal and common, and according to your > description, the person working on dscovr can make changes to sal and > common as well, if needed. So you are focusing on the "read-only" vs "read/write" aspect. > So a search across "current project, as > well as code I edit together with it" This is project-roots. > would include dscovr, sal and common. > > Which sounds useful to me, but I don't really know your workflows. If > the dscovr developer doesn't need to edit sal and common 98% of their > time, maybe they should indeed go into project-library-roots. Yes, the developer will want to search different subsets of the full project at different times. Which is why this needs to be more flexible. The user should be able to specify a subset of the search path for each search, at run-time. Having only project-roots and project-library-roots available is too limiting. > If they only need to edit sal or common for like 5-20% of their work > on dscovr, maybe a finer distinction is needed, like three kinds of > searches: > > - Across project-roots and project-library-roots. > > - project-roots only. > > - The one project roots the current buffer is in. > > Which complicates things a bit, but it's still simpler than having > user predicates and arbitrary metadata. The UI for a predicate is more complicated, yes. But the project.el API is simpler; a single predicate arg is clearly simpler than the confusion between project-roots and project-library-roots. Which is why I keep emphasizing that project.el is _not_ about the UI. >>> Personally, I expect that to be useful (e.g. limiting searches to the >>> projects that you control). But if not, you an also disregard that >>> distinction. Do you see any downsides to it? >> >> Yes; it's not flexible enough. There were times when I wanted to search >> only in map/, or only in sal/. I just used grep-find. > > You can also use C-u M-x project-find-regexp, and point it to map/ or > sal/. Specifying a single directory is relatively easy anyway. Not with the current API: (defun project-find-regexp (regexp) ...) How would I specify a single root or directory? >> The predicate can query the metadata, via project-metadata. > > I can display all available metadata to the user, and ask: directories > with which pieces of metadata set do you want to search? The user > enters the category names, separated by spaces, and the search > proceeds. That would be a dialog-box style UI, yes. > I can't do the same with predicates. I can't even list them all, > really. The dialog box uses the user input to construct a predicate, which it passes to the project.el UI. That's an example of what I had in mind; higher level code implementing a nice UI to drive project.el functions. The alternative to an arbitrary predicate function is to hard-code some set of possible choices in the search code. Any such set is limiting. It may be that we discover some commonly used predicates; they could be standardized in project.el. On the GDS project, one search we repeated often was for FIXME: comments; we had some structure in them, identifying which release it had to be fixed for, who was assigned to fix it, etc. So I could have written a few predicates that take advantage of the structure, and used a menu to select among them for a search. >> We have to agree that the UI is a separate discussion, or we will get nowhere. > > The API should take possible UIs into account. Like described above, Yes. Metadata query functions and search predicates work for a very large variety of UIs (menus, dialog boxes, Siri), as well as a very large variety of searches. "project-roots vs project-library-roots" works for a similar set of UIs but a much smaller set of searches. > if we standardize on metadata, I can imagine at least one UI. If we > standardize on arbitrary predicates, it's much harder. Metadata is provided by the backend to the client code. Predicates are provided by the client code to the backend. They are complementary, not mutually exclusive. > This kind of change to the API should even come with a corresponding > change proposal for xref-find-references, to demonstrate that it's > viable. Yes, I'll put it on my list. -- -- Stephe