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: project.el semantics Date: Wed, 11 Nov 2015 02:47:33 +0200 Message-ID: <56429025.3070008@yandex.ru> 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> <86h9ktah9x.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 1447204482 16519 80.91.229.3 (11 Nov 2015 01:14:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 01:14:42 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 02:14:41 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 1ZwJzj-0003us-Fj for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 02:14:39 +0100 Original-Received: from localhost ([::1]:36942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwJzj-0000Kz-0w for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 20:14:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwJZd-0000B9-62 for emacs-devel@gnu.org; Tue, 10 Nov 2015 19:47:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwJZY-00014o-3d for emacs-devel@gnu.org; Tue, 10 Nov 2015 19:47:41 -0500 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:34918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwJZX-00014h-Q5 for emacs-devel@gnu.org; Tue, 10 Nov 2015 19:47:36 -0500 Original-Received: by wmdw130 with SMTP id w130so93937210wmd.0 for ; Tue, 10 Nov 2015 16:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=piuIUuFpws2aGNbHYtz9eW6izXyIlHJqhzfNdh0rwEc=; b=CX5lDL8A4teJVv8NgtgZBVcitl0zYilc9M5EjJfGd6nWWV9jfMWlDO4baUqQw9DNII xI9Y0TavJMVtaYke2cn2u87M71lwhudeLQiv15gVkkgdUx896Dl1ReOBGKmTZglWuLwF 2A0+iztxYpnf1m3DJr7yedC54PV59sklBMeMiAzeN5xgjr1Qo09X7jbiOOystNMD9Apk qgGr/zf38i6forI5Q6S+joHmkOsFX6SmH7ohBNKGmXiDUz1R9xD79snsGcAUtAco1xjQ wZ9T7VfMeNi/qs3/1oypY+geynbtAgOX2gsZxlxWToov508wIUymgrlGKxkEi464yCEo 1v1Q== X-Received: by 10.28.63.22 with SMTP id m22mr21799238wma.58.1447202855288; Tue, 10 Nov 2015 16:47:35 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id q3sm6207537wjr.34.2015.11.10.16.47.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Nov 2015 16:47:34 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <86h9ktah9x.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:c09::231 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:194023 Archived-At: On 11/10/2015 07:36 PM, Stephen Leake wrote: >> 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. So I'm not adding it. Just keeping that possibility in mind, and hence keeping the word "dependency" free. >> 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. Indeed, I can't account for every variation. So I service just the ones that seem most important to me at this point. > 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. How would they provide the predicate when calling the command interactively? Especially a predicate that would distinguish between project roots and library roots. > You have to rely on common definitions; "dependency" is one (although > apparently not for you, sigh). "outside" is definitely a more common word for me than "dependency". *shrug* > "outside" is a common English word, but "outside the project" is very > fuzzy. You're free to suggest another word that means "not inside of any of the project roots". >> 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". That implies the (not (member ...)) semantics, rather than (not (file-in-directory-p ...)), which is what `project-subtract-directories' actually does. And "not member" semantics seems pointless to me here; we might as well allow project-library-roots to include project-roots element, if the consumer will have to call `project-combine-directories' on them together. Having "library roots" entirely outside the project roots, however, makes a lot of sense to me intuitively: if they're inside, they are a part of the project anyway. What kind of use would we have for such elements? >> 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. Note that neither `elisp--xref-find-references', not `etags--xref-find-references' call `project-prune-directories' (or `project-combine-directories', as it's called now). >> 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. Would you be able to give an example of a project file that lists dependencies like that, that "should be edited together" with the current project? It would fit the manual well. >> 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. If you're waiting for me to start, you might have to wait a while. I haven't written a manual in my life (not in Texinfo, or in English). If you or someone else add the file with structure outline some placeholders a la , that would speed the process considerably. >> 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. semantic-symref is a command that displays references in a tree-like UI, and it uses Semantic on the way to do that. xref-collect-references doesn't. I don't really know a good name for it. xref-collect-references-using-any-cedet-indexing-tool-we-can-find? It's not a user-level command, though, so we can get away with just a mediocre name. > 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. Yes, the manual could be the answer. > I could write a new global xref backend, but it's better to reuse > existing code. Does lisp/cedet/cedet-global.el have code that will help us with implementing "find definitions" using Global? > Unless you are proposing to rewrite symref to be more consistent with > xref. Maybe. Depending on what you exactly mean by that. I'd rather rewrite the "tools" CEDET code to be more flexible, for different uses. >> 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? What code? We have both project-find-regexp and project-or-libraries-find-regexp already, and I find the difference between them useful in practice. > 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. Again, how many project backends will that be? One for every distinct language combination? Basically, you position eliminates the need for project-library-roots-function, as it's used now. I think that we should create a better use for it, and do teach vc-project about library-roots for different project files, through it.