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: Sun, 26 Jul 2015 13:57:56 -0500 Message-ID: <86oaiybvbf.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1437937116 11114 80.91.229.3 (26 Jul 2015 18:58:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jul 2015 18:58:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 26 20:58:26 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 1ZJR7x-0001Uf-DD for ged-emacs-devel@m.gmane.org; Sun, 26 Jul 2015 20:58:25 +0200 Original-Received: from localhost ([::1]:50730 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJR7w-0005sa-QT for ged-emacs-devel@m.gmane.org; Sun, 26 Jul 2015 14:58:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJR7t-0005pT-Kn for emacs-devel@gnu.org; Sun, 26 Jul 2015 14:58:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJR7q-0005no-7K for emacs-devel@gnu.org; Sun, 26 Jul 2015 14:58:21 -0400 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:41047) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZJR7q-0005nb-05 for emacs-devel@gnu.org; Sun, 26 Jul 2015 14:58:18 -0400 Original-Received: (qmail 935 invoked by uid 0); 26 Jul 2015 18:58:11 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 26 Jul 2015 18:58:11 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id xCy31q00M2UdiVW01Cy6CX; Sun, 26 Jul 2015 18:58:10 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv 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=zOBTXjUuO1YA:10 a=vaJtXVxTAAAA:8 a=soUI5UofLVx4Ptmg-HAA:9 a=9_IZr9QhqkhXUqwy:21 a=qsQO_xz2MtiQFbLL:21 Original-Received: from [76.218.37.33] (port=56118 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZJR7b-0003pC-Pj for emacs-devel@gnu.org; Sun, 26 Jul 2015 12:58:03 -0600 In-Reply-To: <55B517AC.5020401@yandex.ru> (Dmitry Gutov's message of "Sun, 26 Jul 2015 20:23:56 +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: 69.89.18.3 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:188098 Archived-At: Dmitry Gutov writes: > In Ruby and Python communities, for instance, it's common to install > the language runtime, with all libraries, inside the developer's home > directory (using RVM/rbenv for Ruby, or virtualenv for Python). And I > might edit some of files there for debugging purposes, but if I forget > about those edits later, only bad can come of it. Likewise, I usually > wouldn't want a global replace operation to touch them. Then it's not "global", is it? It's "operate on this set of projects, exclude that set". So you need a way to specify sets of projects. >>> I'm not sure about that. It seems then the implementation will have to >>> walk the whole project tree itself, and collect all directories that >>> don't match the ignores (because .gitignore syntax allows not-anchored >>> entries for directories). >> >> Yes. You do that once when the project is opened, and cache the result > > And then the user creates a new dir (or switches to a different > branch, revision, etc), and the cache goes out of sync. How do we > handle that? project-cache-refresh. Only the user knows when it should be done; they may want to keep the slightly out of date cache because something isn't finished with the edits yet. >> No, Emacs needs to read the Studio project file and extract the search >> path; it's just another project file syntax. > > But according to you, the "search path" will be just the directories > inside the project's tree, right? No, I have been explicitly saying that is not the case; the search path is whatever the project file says it is. > What will "included projects" look like, in an average Android > project? A list of project names. Depending on the project manager, that implies a list of project files in one syntax or another, each of which specifies a set of project directories (explicitly or implicitly). >> Yes. No different from any other Emacs project; the user has to tell >> Emacs where it is. If that's a directory, Emacs searches for project >> file extensions it knows about, and reads that. If it's a file, no >> searching needed. > > The VC project implementation is currently based on the current > buffer's directory. No need to explicitly specify it, Emacs find the > repo root without user intervention. Yes. > If you've ever tried Projectile, it works in a similar fashion. > Android projects could be detected like that as well. Maybe. Depends on the project manager software. Some have a dominating file, some do it some other way. Why do we care? Just support whatever method the project manger backend requires. project-find-project-file is a dispatching function on the backend. >> Emacs should trust what the project file says; it has an explicit list of >> "source code directories". Emacs should not care whether that contains >> the project file itself or not; that's up to the user. > > Will this miss all the other directories in the project, such as > documentation, maybe? One would expect xref-find-regexp to search > them, too. Trust what the project file says. The user told Emacs to use the project file; it should not try to be smarter. If the user wants documentation in the project, then it is in the project file. If the project manager tool is brain-dead and can't handle documentation, the the user can switch tools. >> Since the external tools that use the project file can report errors in >> its syntax, I usually include the project file in a directory that is in >> the source path. But that's my choice, not Emacs's. > > One would expect xref-find-regexp to search in the project file, too. Only if I tell it to by including it in the project file. If I tell it to _not_ search the project file, it should do that. >> project-root; a single absolute directory, usually containing >> significant files for external tools (ie .git/), often the root of the >> source tree. > > Would we have project-root mainly for the purpose of xref-find-regexp > being able to search in the project file? No. We should have project-root for tools that need a root directory. xref-find-regexp needs a search path, not a root directory. > If project-root is not in project-search-path, can there be other, > unrelated files in that directory? How would we make sure > xref-find-regexp ignores them? xref-find-regexp searches project-search-path. project-search-path is set by reading the project files. The project files are provided by the user. Voila, xref-find-regexp does _exactly_ what the user wants, no more, no less. -- -- Stephe