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 01:26:34 +0200 Message-ID: <5643CEAA.6000103@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> <86mvwn11u1.fsf@stephe-leake.org> <55F8E451.9080902@yandex.ru> <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> 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 1447284442 27185 80.91.229.3 (11 Nov 2015 23:27:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 23:27:22 +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 00:27:12 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 1ZwenE-0004or-OD for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 00:27:08 +0100 Original-Received: from localhost ([::1]:43630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwenD-0005qK-M7 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 18:27:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwemq-0005pc-Uo for emacs-devel@gnu.org; Wed, 11 Nov 2015 18:26:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwemk-0003Kb-Jc for emacs-devel@gnu.org; Wed, 11 Nov 2015 18:26:44 -0500 Original-Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:36904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwemk-0003K3-Ab for emacs-devel@gnu.org; Wed, 11 Nov 2015 18:26:38 -0500 Original-Received: by wmww144 with SMTP id w144so65448045wmw.0 for ; Wed, 11 Nov 2015 15:26:37 -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=clJZMVFsyO3qQU7SijrbX5inTbh6M63STamSQuGBf9k=; b=iBUMcGe1iAX80CxKgtvPmJmQJoSzLhrb3i0y9IJ5znx88G9mx+T3HW+4yYrrbf2aNs UG+47EfjskkKR5cQtgkCyynModQujkWlHIRq2SIZ/O2Ao68w8k20i9axNcfXmlA+3ueQ QYC4N022WlCF/IKc/hg2U6f2r/WigRgQ2dp5bgWwc06p2IpDTPR2iCH+02H542R99aWX qBkrvllzjNBSPMVirOki6Jwk5sMj8Wno6pIMGrf5x/3ZJVvr5TlV6iA8W4e67HlKz6Zm kj5FdpSl/zep4tLHWkMgH2BhuDB7GCsmAwVQnvInKVhU1YQkSSF2rqwLYwT3i00L4++D sNoA== X-Received: by 10.194.249.97 with SMTP id yt1mr11826933wjc.89.1447284397442; Wed, 11 Nov 2015 15:26:37 -0800 (PST) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id e63sm27646265wma.7.2015.11.11.15.26.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Nov 2015 15:26:36 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <86wptob2v6.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::232 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:194170 Archived-At: 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), it might be "library", and/or something else. > Used to; I'm retired now. That's a pretty good job as well. :) >> 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 a search across "current project, as well as code I edit together with it" 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. 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. > I'm left with "in order to decide which directories go in project-root > vs project-library-root, ask Dmitry". Everybody should Ask Dmitry more often. >> 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. > I could only dream about the other use cases I described, but they did > come up. For refactoring, I would make a low-level change, that would > generate lots of compiler errors (Ada is a big help here). Then I would > maintain a manual list of which ones were fixed in a text file. I save test errors log from the Compilation buffer to file too, from time to time. > Some more structured system would be nice. I think a harder question would be, how do you want the list to be updated. Apparently you don't want to just recompile the whole project, or you wouldn't need the text file. >> I'm hoping that you can still distinguish sal and common from the >> standard library somehow, programmatically. > > Only by knowing the directory layout of the disk; the Ada project > doesn't care, so it doesn't know. If all else fails, they could be tagged with a directory-local variable, via .dir-locals.el. That would also give the choice of "is this library or not" to the user. > Right. On the other hand, a user-defined predicate would be a > reasonable feature for xref-find-references. It might be. > 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. I can't do the same with predicates. I can't even list them all, really. > 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, if we standardize on metadata, I can imagine at least one UI. If we standardize on arbitrary predicates, it's much harder. 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.