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: Unified project interface Date: Sat, 01 Aug 2015 04:50:47 -0500 Message-ID: <86lhdvjq14.fsf@stephe-leake.org> References: <557039DB.4060607@yandex.ru> <85d21bbkqf.fsf@stephe-leake.org> <5570E86B.8070200@yandex.ru> <85iob2a2mm.fsf@stephe-leake.org> <55B2CDA4.8020207@yandex.ru> <868ua5caz6.fsf@stephe-leake.org> <55B441DD.9060806@yandex.ru> <86zj2jb1tx.fsf@stephe-leake.org> <55B517AC.5020401@yandex.ru> <86oaiybvbf.fsf@stephe-leake.org> <55B62B53.5060003@yandex.ru> <861tftaxgx.fsf@stephe-leake.org> <55B78F49.6010101@yandex.ru> <868ua09s1y.fsf@stephe-leake.org> <55B7CD86.20306@yandex.ru> <86oaiv8zqn.fsf@stephe-leake.org> <55B9590C.3080108@yandex.ru> <86wpxi6ovl.fsf@stephe-leake.org> <55BABE27.4040105@yandex.ru> <868u9wz4mw.fsf@stephe-leake.org> <55BC197C.3050006@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438422696 20010 80.91.229.3 (1 Aug 2015 09:51:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Aug 2015 09:51:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 01 11:51: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 1ZLTRt-00074k-7H for ged-emacs-devel@m.gmane.org; Sat, 01 Aug 2015 11:51:25 +0200 Original-Received: from localhost ([::1]:53139 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLTRs-0004Tc-2Z for ged-emacs-devel@m.gmane.org; Sat, 01 Aug 2015 05:51:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50816) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLTRf-0004TI-Fv for emacs-devel@gnu.org; Sat, 01 Aug 2015 05:51:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLTRb-0005mF-DO for emacs-devel@gnu.org; Sat, 01 Aug 2015 05:51:11 -0400 Original-Received: from gproxy6-pub.mail.unifiedlayer.com ([67.222.39.168]:60907) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZLTRb-0005kb-6b for emacs-devel@gnu.org; Sat, 01 Aug 2015 05:51:07 -0400 Original-Received: (qmail 2672 invoked by uid 0); 1 Aug 2015 09:51:03 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 1 Aug 2015 09:51:03 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id zMqu1q00e2UdiVW01MqxQ9; Sat, 01 Aug 2015 03:51:01 -0600 X-Authority-Analysis: v=2.1 cv=O9qq4nNW 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=y7kgw_RnJtkA:10 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=uRRa74qj2VoA:10 a=vaJtXVxTAAAA:8 a=waTNpI4bjuHmSlHuwoAA:9 Original-Received: from [76.218.37.33] (port=63512 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZLTRQ-0001C9-Hy for emacs-devel@gnu.org; Sat, 01 Aug 2015 03:50:56 -0600 In-Reply-To: <55BC197C.3050006@yandex.ru> (Dmitry Gutov's message of "Sat, 1 Aug 2015 03:57:32 +0300") 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:188259 Archived-At: Dmitry Gutov writes: > On 07/31/2015 07:13 PM, Stephen Leake wrote: > >> Which is faster/friendlier depends on the details, so we'll have to wait >> for actual implementations. All I'm asking is that we do not make design >> decisions at the generic project API level that rule out this approach. > > We do have to make some decisions, though. For instance, supporting > both recursive and non-recursive elements in search-path will require > a separate code path for each function that uses it. > > As such, it will require a separate code path in xref-collect-matches > and an alternative for xref--rgrep-command. Or they could abort; that would be ok while we are experimenting. It may be that one or the other will turn out to be The Right Way. A backend that uses flat paths doesn't have to use those functions. Or, the people writing that backend can modify them if that seems better than putting similar code elsewhere. That would be part of the cost of that design decision. >> I would provide a special syntax to handle this in >> project-add-search-path: >> >> (defun project-add-search-path (project path &optional make-recursive) >> "Add PATH (a list of directories) to the search path for PROJECT. >> >> If a directory in PATH ends in \"/**\", also add all directories under >> that directory. >> >> If MAKE-RECURSIVE is non-nil, the full project search path is pruned so >> that only highest-level directories are present, and all uses of >> `project-search-path' recurse into subdirectories. In this case, it is >> likely you will also need to specify ignored directories with >> `project-add-ignores'. >> >> If MAKE-RECURSIVE is nil, uses of `project-search-path' no not recurse >> into subdirectories." >> ... ) >> >> The Ada project files support the ** sytnax. >> > This description explains the purpose, but doesn't describe the > resulting data structure that would hold that information. The ones > that come to mind are rather ugly. I have no idea what data structures come to mind for you. This could be implemented with a root projects type: (cl-defstruct (projects) user-search-path ;; list of directories added to project-search-path user-ignores ;; list of ignores added to project-ignores recursive-search-path ;; if non-nil, project-search-path is treated as recursive in all usees ... ) Is that "ugly"? > The /** syntax is rather nifty. But why do you propose to have it and > MAKE-RECURSIVE at the same time? We could just interpret /** as the > recursive marker. Then the result could be a list of strings. Because you never need both. If you are used to using recursive paths, adding ** in the path to tell the code that will seem odd. So it seems best to have an explicit flag. It might be better to specify the recursive flag in the project constructor; then this function would check it, not set it. >> This could be handled if the user can explicitly specify project ignores >> (not just rely on .gitignore etc; git does _not_ ignore the lisp-emacs-* >> and ada directories). More complicated structures are harder to handle >> with ignores; you'll end up with a long flat list of ignores, so it >> might be simpler to have a flat list of includes instead. > > I've just started to write about this... Yes indeed, I think every > flat structure can be translated into path/to/dir, plus path/to/dir/*/ > in the ignores. The translation function shouldn't take too much work > to write. The reverse is also true; it is possible to convert recursive path/ignores into flat path/ignores. > There's no need to produce the list of ignores manually. Only if you ignore the use cases I posted. There are situations where the algorithm will not do what the user wants. The fact that you don't like them does not mean they are not valid. Would it be such a problem to provide 'project-add-ignores'? >> Me, and many other teams at NASA - structures similar to the above, >> where the non-included directories can also be release version, >> debug/release options, target hardware/os option, compiler >> vendor/version, etc. > > There can be different opinions about this. Yes, precisely. And Emacs core should not be enforcing any opinions! >>>> So move it to "location" instead of "xref". The longest journey starts >>>> with one step ... >>> >>> Until it's used in at least two different places, creating a separate >>> package for it is, I think, premature. >> >> Right. We now have those two places; xref-find-definitions, >> project-find-regexp. > > Both still use xref for display. The location values aren't consumed > by anything else. So that's just one place. They both display locations. The code that displays locations should also be in the locations namespace, not the xref one. -- -- Stephe