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, 07 Jun 2015 20:59:12 -0500 Message-ID: <85zj4barkf.fsf@stephe-leake.org> References: <557039DB.4060607@yandex.ru> <85d21bbkqf.fsf@stephe-leake.org> <5570E86B.8070200@yandex.ru> <85iob2a2mm.fsf@stephe-leake.org> <5574D0AF.2090608@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1433728801 22754 80.91.229.3 (8 Jun 2015 02:00:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Jun 2015 02:00:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 08 03:59:47 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 1Z1mLn-0003Pz-V2 for ged-emacs-devel@m.gmane.org; Mon, 08 Jun 2015 03:59:44 +0200 Original-Received: from localhost ([::1]:55622 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1mLi-0000aD-7U for ged-emacs-devel@m.gmane.org; Sun, 07 Jun 2015 21:59:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1mLV-0000a6-BV for emacs-devel@gnu.org; Sun, 07 Jun 2015 21:59:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1mLS-00041n-2I for emacs-devel@gnu.org; Sun, 07 Jun 2015 21:59:25 -0400 Original-Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]:33016) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Z1mLR-00041H-Ng for emacs-devel@gnu.org; Sun, 07 Jun 2015 21:59:21 -0400 Original-Received: (qmail 6097 invoked by uid 0); 8 Jun 2015 01:59:18 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 8 Jun 2015 01:59:18 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id djs41q00Y2UdiVW01js7BS; Mon, 08 Jun 2015 01:52:07 -0600 X-Authority-Analysis: v=2.1 cv=D8zUdJhj 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=rMLPtTzFGpYA:10 a=XAFQembCKUMA:10 a=vaJtXVxTAAAA:8 a=RtkggBvCAAAA:8 a=vk4ZeLbAm6nPo8NhjtsA:9 a=t1qqjOap9hwA:10 a=GxXBWe2gE3YA:10 Original-Received: from [12.52.181.2] (port=49543 helo=TAKVER) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z1mLL-0000E4-Ju for emacs-devel@gnu.org; Sun, 07 Jun 2015 19:59:15 -0600 In-Reply-To: <5574D0AF.2090608@yandex.ru> (Dmitry Gutov's message of "Mon, 8 Jun 2015 02:15:59 +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 12.52.181.2 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:187086 Archived-At: Dmitry Gutov writes: > On 06/05/2015 01:08 PM, Stephen Leake wrote: > >> No problem; make sure that directory is in project-source-directories. > > How would that work, in technical terms? Which entity will "make sure" > of that? The user; they are the only ones that know what "the project" is. > Will a project-backend "source directories" implementation > always cl-call-next-method? I don't understand this. > Will the default impl simply return the value of some variable, > assigned by a major mode? default implementation of what function? >> README is a perfectly valid source file; it is written in the "plain >> text" language (for which no compiler is needed ;). > > I see a few problems with that: > > - README has no source code (it doesn't affect the logic of any > program). It's the other way around; there is no object code corresponding to the README source code. But that's not very significant. > "sources" already has a common meaning, What is that? I take it to mean "any human-readable file". Which thus includes README, Makefile, .git/config, etc. > and at least in one proprietary editor it's just one a subset of all > project files (see the nomenclature here: > https://www.jetbrains.com/idea/help/content-root.html). That gives me 404 > Further, if we can separate them, we could make sure > xref-find-references only searches in the "proper" source directories. What do you mean by "proper"? We need it to search what the user wants to search; the user needs to be able to specify that clearly and easily. > - There's no direct way to find the directory holding the README when > you only have the value of load-path or compilation-search-path If the user specifies compilation-search-path (directly or indirectly), and the user wants to be able to search README, then the user must include the directory containing README in compilation-search-path. Is that a problem? > So it would make sense to have a different name (and a different > function/slot/etc) for directories that might be reached that way. I don't follow; can you give more details, and a clear example? >> 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). > > xref should take the language into account, but it should work across > them as well. For instance, a Ruby method call in an *.html.erb > template file should get recognized as a reference to that method, and > its "find definition" should lead to the corresponding *.rb file. Ah. Now you are talking about one file that mixes source in two languages. Yes, that is a problem. There have been discussions here of multi-mode files. I don't know how that would work in practice. I have projects that mix Ada and C++; the project level cross reference facility handles both, using the current xref API. That works because gcc generates the same cross reference info for those two langauages; I doubt there is something similar for Ruby and html. >> It might make sense to parameterize project-source-directories >> with a language (or major-mode) name, to get the corresponding subset. > > That's probably not necessary: after all, only the default > xref-find-references implementation will use > project-source-directories in a naive way. A smarter xref backend > should determine itself which directories to search. I don't see how that is at all possible, especially in the face of hierarchical projects. Only the user knows what a "project" is; they write the hierachical project files that tell the system what the project structure is. >> 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-ignore-directories should be a thing. Probably in the format > of grep-find-ignored-directories (and we might have a function > corresponding to grep-find-ignored-files). Trouble is, > projectile-ignored-directories seems to be more flexible already, so > maybe that will have to be accompanied with an upgrade to how > grep-find-ignored-directories are handled. > >> 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. > > Like mentioned above, for example, the distinction would help with the > default xref-find-references implementation. You seem to be missing my point; I see no need for project-root, outside of configuration management. So I don't see why xref should care about "root" at all. >>> 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? > > Some package that defines that root-finding logic. Not every major > mode knows where the relevant source directories are, or it might not > know some of them. As I've said, none of the languages I deal with care about a "root" directory. Only git, mtn, cvs care. Hmm. Java imposes something like a root by forcing the directory structure to match the hiearchical package naming. But referencing other package hierarchies complicates that, just as in Ada and C++. > If we've opened one of the files in a third-party Elisp project that > hasn't been loaded yet (so not in load-path), a project implementation > can still add an element or several to project-source-directories, so > that xref-find-references returns somewhat useful results anyway. What does that have to do with "root"? The third-party elisp file will presumably have some paths in "(require ...)" forms that will define a set of directories to be added to project-source-directories. > Or, say, for Ruby: while the major mode might conceivably be taught > about paths where to find system-wide libraries, the locations of > source files in a given project depend on the project's type, and that > must be something a project implementation knows better. Even if it'll > simply add the root to project-source-directories. What "root"? Is that the directory containing the Ruby file that we opened? Why is that a "root" as opposed to just some source directory? -- -- Stephe