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: Tue, 10 Nov 2015 11:36:10 -0600 Message-ID: <86h9ktah9x.fsf@stephe-leake.org> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <86mvwn11u1.fsf@stephe-leake.org> <55F8E451.9080902@yandex.ru> <86bnd21q0r.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447177033 7007 80.91.229.3 (10 Nov 2015 17:37:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Nov 2015 17:37:13 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 10 18:37:02 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 1ZwCqq-0005Vv-U9 for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 18:37:01 +0100 Original-Received: from localhost ([::1]:34487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwCqq-0003Sg-Dm for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 12:37:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwCql-0003SG-Ek for emacs-devel@gnu.org; Tue, 10 Nov 2015 12:36:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwCqi-0006U9-7p for emacs-devel@gnu.org; Tue, 10 Nov 2015 12:36:55 -0500 Original-Received: from gproxy9-pub.mail.unifiedlayer.com ([69.89.20.122]:33387) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZwCqi-0006Ow-0o for emacs-devel@gnu.org; Tue, 10 Nov 2015 12:36:52 -0500 Original-Received: (qmail 1984 invoked by uid 0); 10 Nov 2015 17:36:28 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 10 Nov 2015 17:36:28 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id ftcL1r01M2UdiVW01tcPka; Tue, 10 Nov 2015 10:36:28 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa 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=vaJtXVxTAAAA:8 a=HHRudnjmlGOWpJZCVKkA:9 Original-Received: from [76.218.37.33] (port=50701 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZwCqC-0001TG-C9; Tue, 10 Nov 2015 10:36:20 -0700 In-Reply-To: <56415902.90103@yandex.ru> (Dmitry Gutov's message of "Tue, 10 Nov 2015 04:40:02 +0200") 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.20.122 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:193891 Archived-At: Dmitry Gutov writes: >> You can easily get the project from the directory, and you can easily >> search the directory. So the directory is more useful. > > I don't know about that. If you only know the directory, you're at the > mercy of project-find-functions. If (project-dependencies project) > returns project instances, however, you're free to choose the right > project implementation to use for them, set up "parent project" > references, use some other information from the current project file, > and so on. > > Although again, what will the project dependencies be used for, is > still an open question for me. The general rule is: if we don't have a good use case, don't add code. >> I don't see the point of making that distinction here; the files in >> non-editable places will be read-only. Non-edit does not imply >> non-search. > > In dynamic languages that I've used, the library files are often > perfectly editable. You just don't want to do that, most of the time. > > Another thing you might want to do - replace some term across the > project (using M-x project-find-regexp and then M-x > xref-query-replace). If we were to show its occurrences in library > files as well, that would be a waste of user's and computer's time. You can't allow for all possible user desires by providing different path functions at this level. Instead, there should just be one path, that includes all files that the user might want to do anything with. Then, when the user actually invokes a function to do something, they can provide a predicate if they want a subset of that. >>> I'm using "outside" as "directory terminology". >> >> So what would be wrong with including both ways of describing it, so >> more people understand what is wanted? > > I generally try to get away with using as little words as possible > when describing something, because words can be misunderstood, > especially new ones, which haven't been used before in the given > context (such as "dependency"). "outside" is a new word in that sense. You have to rely on common definitions; "dependency" is one (although apparently not for you, sigh). "outside" is a common English word, but "outside the project" is very fuzzy. > Since we're discussing project-library-roots here, I'm not sure which > improvement you mean. How about simply replacing "the list of > directories outside of the project" with "the list of directories > outside of the project roots"? I suggest "not included in" rather than "outside". > Because if we describe it in terms of dependencies, a dependency might > be checked out inside a project root subdirectory in certain > configurations (maybe with an appropriate .gitignore entry, maybe > not). In that case, though, we probably don't want to have > project-library-roots include it. Why not? We allow subdirectories in the same path in general (ie `load-path'); that's what project-prune-directories is for. > We can add "So if the project has dependencies which should be edited > together with it, they should go here as well." to the third paragraph > of the project-roots docstring. That would be good. >> So provide alternate wording that uses the concepts "separate projects" >> and "dependencies", and says what you want it to say. >> >> People will want to know. > > Guess that might go into the manual instead. I've seen someone state > that it's okay for the manual to have redundancies. Ok, please start the manual. That would help a lot. >> Right; so project-find-references should be a cl-defgeneric. > > Keep in mind that the current Grep-based "find references" are sloppy, > best-effort implementations. It's not like we expect the users to use > them when there's any other alternative. Right; that's what default implementations of generic functions are for. >> xref-collect-references would be better named >> xref-semantic-find-references; it is a semantic implementation of >> xref-find-references. > > It's a... semantic-symref-tool implementation of it, actually. Which > has no relation to Semantic grammars, its tags, or etc. Ok, so xref-semantic-symref-find-references, or xref-symref-find-references. > And I'm seriously considering to get away from it and always use Grep, > because the other tools, while they can be faster, they're also > entirely opaque to the user, can have outdated databases, non-indexed > relevant directories, unsupported languages, and so on. But if I normally use global, I want xref to use it. And I know how to deal with all those issues. Although some details in the manual would help. I could write a new global xref backend, but it's better to reuse existing code. Unless you are proposing to rewrite symref to be more consistent with xref. >> It's simpler to avoid the whole issue and merge project-roots and >> project-library-roots, at least in this first iteration of the project >> API. Then we can find out if people actually want a choice of paths. > > IMO, it's more important to have the distinction between "project > roots" and "project library roots" in "find regexp" than in "find > references". But you don't provide any code that allows the user to take advantage of that distinction. So it how important can it be? >>> Where I come from, it's common enough to have several "project files", >>> so to speak, at the top of a project, coming from different languages. >>> For instance, having both Gemfile and package.json. >> >> I would merge multiple project files into one Emacs project, not have >> different Emacs projects for each language. > > And to do that, vc-project needs to know how to get library-roots from > each of those project files. From a hook. Right? No, I would not expect vc-project to know anything about project files. I would write a new project backend that knows about some set of project files. -- -- Stephe