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: Fri, 05 Jun 2015 05:08:49 -0500 Message-ID: <85iob2a2mm.fsf@stephe-leake.org> References: <557039DB.4060607@yandex.ru> <85d21bbkqf.fsf@stephe-leake.org> <5570E86B.8070200@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1433498991 14821 80.91.229.3 (5 Jun 2015 10:09:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2015 10:09:51 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 05 12:09:40 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 1Z0oZ5-0006yA-9L for ged-emacs-devel@m.gmane.org; Fri, 05 Jun 2015 12:09:27 +0200 Original-Received: from localhost ([::1]:46223 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0oZ4-0003sU-0v for ged-emacs-devel@m.gmane.org; Fri, 05 Jun 2015 06:09:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0oYn-0003sO-GL for emacs-devel@gnu.org; Fri, 05 Jun 2015 06:09:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0oYk-0002mZ-9I for emacs-devel@gnu.org; Fri, 05 Jun 2015 06:09:09 -0400 Original-Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]:50819) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Z0oYk-0002lB-1r for emacs-devel@gnu.org; Fri, 05 Jun 2015 06:09:06 -0400 Original-Received: (qmail 1155 invoked by uid 0); 5 Jun 2015 10:09:00 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 5 Jun 2015 10:09:00 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id ca1J1q0032UdiVW01a1Mt3; Fri, 05 Jun 2015 04:01:24 -0600 X-Authority-Analysis: v=2.1 cv=efyuId0H c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=2wGvvwaKUHMA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=XAFQembCKUMA:10 a=vaJtXVxTAAAA:8 a=PTJySxN9prx21MgQMvkA:9 Original-Received: from [76.218.37.33] (port=50079 helo=TAKVER) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z0oYX-0001vu-Ix for emacs-devel@gnu.org; Fri, 05 Jun 2015 04:08:53 -0600 In-Reply-To: <5570E86B.8070200@yandex.ru> (Dmitry Gutov's message of "Fri, 5 Jun 2015 03:08:11 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (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.33.93 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:187031 Archived-At: Dmitry Gutov writes: > On 06/04/2015 05:40 PM, Stephen Leake wrote: > >> The list of directories that xref-find-regexp needs to search is not >> the project root; it is the list of directories included by the project >> source code. > > Not exactly. xref-find-regexp is interested in all kinds of files, not > just source files. That includes, say, the README file at the top of > the project. No problem; make sure that directory is in project-source-directories. README is a perfectly valid source file; it is written in the "plain text" language (for which no compiler is needed ;). I have no problem with projects including more than one language in the sources; most of mine have Ada, Texinfo, LaTeX, text, elisp, and make source code. Which is one reason why project and xref cannot be merged (xref must be language-specific, even for tags). It might make sense to parameterize project-source-directories with a language (or major-mode) name, to get the corresponding subset. >> For that you need a function like "project-source-directories", which >> could be customized for each project backend. > > However, you raise an interesting point. Whereas xref-find-references > would like to search in all load-path directories, 'load-path' is an elisp notion. For other languages "source-path" is more appropriate. > maybe it would be enough if xref-find-regexp only searches inside the > current "project root", for some definition of that notion. No, xref-find-regexp should search project-source-directories. Most real projects include other projects, so limiting the search to only the top project is wrong in general (although that might be a useful option in some use cases). In addition, there might be a directory under project root that should _not_ be searched; the object file directory for ada-mode, for example. project-source-directories should return the union of the source directories for all of the included projects. That's what load-path is for elisp, and what compilation-search-path is for ada-mode and other language modes. For elisp, project-source-directories should simply return load-path. > I wonder how we could make it work this way. Make "project root" an > orthogonal feature? If you mean "orthogonal to source directories", then yes, that is what I am suggesting. >> The ada-mode project file can be anywhere; in my projects, it is usually >> _not_ at the "project root directory", but down one or two layers in >> build/ or build/release/. > > We can't rely on every Elisp project declaring a "project root" in the > same way, though. We can make it a requirement in order to use the general tool. But first we have to justify it; ada-mode has never needed that notion; neither has elisp. In my experience, only config management needs it. >> Hmm - vc could query for the current project root, and ada-mode would >> provide the answer. That might be useful, and a good reason to have a >> unified project interface. > > VC is one option for this. Or the project may be not registered in any > VCS yet, and the root would be determined based on, say, the presence > of configure.ac. Again, this suggests that notions of "source > directories" and "project root" can be somewhat orthogonal. Not just "somewhat"; "completely" :). It also points out that "project root" is poorly defined; I think that is because it's not at all clear when and why we need it. > On the other hand, after the project root is determined, it might want > to add some new element(s) to the source directories list. "it" is what here ? Can you give an example? >> There are lots of project meta-data that the ada-mode project file syntax >> provides; compiler options, object directory, case exceptions, etc. Some >> of those might be common with other projects. > > Right. We'll need those pieces of metadata that are useful to more > than one subsystem, and can be employed in a general way. Though a > generic metadata storage might be useful as well: thus, if some minor > mode has read the project file and parsed the compiler options, it can > set the related metadata, so that code completion and linter could use > it without waiting for Emacs core to standardize it. ada-mode uses a plist to represent the project metadata, and has examples of minor modes adding to the plist. -- -- Stephe