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: Unified project interface Date: Sun, 26 Jul 2015 20:23:56 +0300 Message-ID: <55B517AC.5020401@yandex.ru> 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> 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 1437931452 12141 80.91.229.3 (26 Jul 2015 17:24:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jul 2015 17:24:12 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 26 19:24: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 1ZJPel-0003E8-8x for ged-emacs-devel@m.gmane.org; Sun, 26 Jul 2015 19:24:11 +0200 Original-Received: from localhost ([::1]:50584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJPek-0004Sc-Gu for ged-emacs-devel@m.gmane.org; Sun, 26 Jul 2015 13:24:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJPeg-0004SX-1O for emacs-devel@gnu.org; Sun, 26 Jul 2015 13:24:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJPeb-00040v-Va for emacs-devel@gnu.org; Sun, 26 Jul 2015 13:24:05 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:38748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJPeb-000406-Km for emacs-devel@gnu.org; Sun, 26 Jul 2015 13:24:01 -0400 Original-Received: by wibxm9 with SMTP id xm9so88487830wib.1 for ; Sun, 26 Jul 2015 10:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=VIQQYaNaNgzCTJIWirfgaD+x29RC1MlJGunss0a9Xf4=; b=CS2Vo6W/cdDj0mQcIS5GXkv4ofEDk7cq/pFHpB7DZPZKvm3QE+KJG0FxNpe/oFR2NY BripIg3y22OXlh+t0G8fZWipzXmmpUBAVd3/3uNXez9tQRI25LvZpErxeW9ykJlFrCU+ qLKhgN0ZyQ5OLpwSroXfUgWk5BR6w2RSEY5qcYh2dbvHk+PNz23Tx51JCVpCBFoaYqMw nxWFJNsrl9c09fxRCaBF4cqt0+yOVnZ8N+t7GCCSbcLBRW/OAKwYCI35ytHYn7t64uRA 9J+Dvchrjgy7tbqtAapMQFc9zXdJAPliCjGSX5IROtcjw1j0a6Gw7dy9eo1G0mcLHZ5x vJCQ== X-Received: by 10.180.109.6 with SMTP id ho6mr16736219wib.58.1437931440948; Sun, 26 Jul 2015 10:24:00 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id gb16sm9207742wic.5.2015.07.26.10.23.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2015 10:23:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <86zj2jb1tx.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:c05::22d 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:188097 Archived-At: On 07/26/2015 02:22 PM, Stephen Leake wrote: > Yes; any third party library that you should not edit, because the > sources are controlled upstream. Is it common to have its sources checked out in a directory nearby? > Ok. I don't see the notion of "system directories" as important here; > the important point is whether the libraries are read-only or > read/write. We should not rely on where they happen to reside to decide > that; sometimes I edit "system directories" when working on patches for > upstream. There is a difference, from my perspective: usually, there are no object files in system libraries, no build files, or .gitignore files. > Or just ignore the read-only issue in the project code; file permissions > are good enough. Maybe ignoring that is fine (are we backtracking on the separation of the directories for the purposes of search and edit operations?), but file permissions won't help in a lot of cases. 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. >> 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? On the other hand, delegating the scan of the filesystem to 'find' seems performant enough. Someone correct me if I'm wrong, but most of the time is spent in Grep anyway. > in the variable project-search-path. Then all code that searches > projects is simpler; it deals with a simple list of directories, plus a > list of file extensions (just as locate-file does). locate-file seems to use a whitelist of suffixes, which is distinctly less powerful than with what's offered by .gitignore. I think keeping compatibility with it (and similar .bzrignore and .hgignore) is valuable. > 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? That can be determined solely on the location of that file. What will "included projects" look like, in an average Android project? > 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. If you've ever tried Projectile, it works in a similar fashion. Android projects could be detected like that as well. > 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. > 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. > 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? 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? Seems like any other tool that would use it would be specific to that kind of project (such as project file checker). Maybe the path to the project file should be set via metadata, using a key like ada-project-file. > note that the _only_ requirement here is that it is a single > absolute directory; the rest is just suggestions. That's a problem, IMO. If project-root is loosely defined, it's not useful to third-party code that doesn't know much more about your kind of project. And as per below, we're be including source directories from both the current project and the included projects into project-search-path, right? Seemingly on equal rights. But then, each of those projects likely has a .gitignore, a build file, and so on, but project-root will only return the location of project files for the current project? That seems inconsistent. > project-search-path; a list of directories, containing files related to > the project. This will normally include project-root. It may also > contain included projects. So, this tries to combine project-search-path and project-directories, as they're defined now? From the previous email, I imagined a project-specific project-search-path plus an accessor like project-dependencies, which would contain a list of project objects corresponding to the included projects. > this might want to be split into project-source-search-path, > project-object-search-path, but since Emacs is mostly interested in > editing sources, only the source path is interesting. Right. I'd call it project-directories, though.