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 16:41:54 -0600 Message-ID: <86si4cb1l9.fsf@stephe-leake.org> References: <86pp1j4ejm.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> <564374E7.50600@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447281834 18395 80.91.229.3 (11 Nov 2015 22:43:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 22:43:54 +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 23:43:39 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 1Zwe78-0000mq-Mh for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 23:43:38 +0100 Original-Received: from localhost ([::1]:43389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwe77-0003G5-MC for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 17:43:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwe6Y-0003De-Ht for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:43:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwe5c-00014F-8t for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:43:02 -0500 Original-Received: from gproxy4-pub.mail.unifiedlayer.com ([69.89.23.142]:54082) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Zwe5c-000147-1a for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:42:04 -0500 Original-Received: (qmail 2514 invoked by uid 0); 11 Nov 2015 22:42:00 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 11 Nov 2015 22:42:00 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id gVht1r01W2UdiVW01Vhwal; Wed, 11 Nov 2015 22:41:58 -0700 X-Authority-Analysis: v=2.1 cv=Caqbutbl 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=pGLkceISAAAA:8 a=vaJtXVxTAAAA:8 a=RhbOF3jDvUgou5A2r38A:9 Original-Received: from [76.218.37.33] (port=49864 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zwe5T-0002Hy-Rk; Wed, 11 Nov 2015 15:41:56 -0700 In-Reply-To: (John Wiegley's message of "Wed, 11 Nov 2015 09:22:02 -0800") 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: 69.89.23.142 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:194166 Archived-At: John Wiegley writes: >>>>>> Dmitry Gutov writes: > >> It's supposed to be a generic replacement for the top-level EDE ede-project >> class, more or less. > > Except I don't know what that is. :( Previouslyl, we have said that a project.el object is not a replacement for EDE projects. It makes sense for project.el to be used as a wrapper for EDE projects. The project.el header says it fairly well: ;; This file contains generic infrastructure for dealing with ;; projects, and a number of public functions: finding the current ;; root, related project directories, search path, etc. ;; ;; The goal is to make it easy for Lisp programs to operate on the ;; current project, without having to know which package handles ;; detection of that project type, parsing its config files, etc. EDE can be used as a project.el backend, to do the "detection of project type, parsing its config files, etc". projectile could be another backend. elisp packages that interface with build tools like ant or maven could be other backends. Then higher level code, like locate-file or xref-find-definition, can use the project.el API to access project features. Mostly search-path, at the moment; the intent is that there be other project features in the future. > OK, this is starting to make more sense now. So, you're saying that *within* a > project there are both distinguished directories, and file subsets with common > meaning; and *outside* the project (say, in "/usr/include"), that are likewise > distinguished directories and file subsets with common meaning. > > What we may want to do is avoid the concept "root" entirely, and talk instead > about general "filesets": That is, every "project" would have 0 or more > associated filesets, Yes, I think roots (more precisely, a list of roots and ignores, or an explicit list of directories like `load-path') is a proxy for the project fileset. > and a way to identify which project (perhaps multiple!) > that a given buffer is associated with. Yes; that's project-current. > A fileset could be defined as: > > Everything within a directory > Everything within a directory tree > Everything within a directory or tree matching a predicate or: Everything within the directory trees on a path > In the most general case, a fileset is determined by whatever function the > user provides in .dir-locals.el. That's not the most general case; that's just one particular project backend; the vc backend. Other project backends, for EDE or gradle, will have other ways of defining the filesets. I'm working on implementing a couple of these, but I don't seem to be moving very fast on it. > Filesets in turn have an extensible set of attributes: > > Is the file part of the project, or external to it? There are actually three categories: - member of the top level project - member of a dependency of the top level project - everything else So, if "the project" is defined as "all elisp files on load-path", then foo.c is in "everything else", even if it is in a load-path directory. > Is it under version control? Emacs already has a standard API for version control, but it might make sense to wrap it in a project metadata structure. > Is it a build product? That would be useful. > Should it be searched, tagged, presented in various contexts, etc.? > (This itself might be an extensible sublist) Some of this can be a permanent attribute of the file, but it depends on the context. As I pointed out in another message, some contexts (like "refactor foo") are transient, and defined by the user, not the fileset. > This way we can talk in general terms, and not about concrete roots or > directories. In the most abstract case, the notion of "project" should be > entirely definable by the user, Better, "definable by the backend". I reserve "user" in this case for the person that is running the code that uses project.el. The project backends define what attributes the project filesets can have. But maybe you meant something like "the user writes the project files that the build tool uses" and which the project backend uses to define what the project is; that's true. > and may look nothing like what we presently have in mind. It's even > possible that a buffer without an associated file, say a *Compilation* > buffer, could momentarily be considered part of a project, and as a > candidate for cross-buffer searching within that project. Right; clearly a compilation buffer should be associated with a project. Currently, since project-current uses directory-based project detection, this works well. EDE relies mostly on directory-based detection as well. I prefer letting the user specify a single active project; that way the same search path is used no matter what buffer a search is started from. That's partly because that's what the ada-mode code does (I maintain ada-mode, and used it extensively at NASA); I'm trying to see what advantages there are to a more fragmented project approach. -- -- Stephe