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: progmodes/project.el and search paths Date: Wed, 12 Aug 2015 12:28:07 +0300 Message-ID: <55CB11A7.2020806@yandex.ru> References: <55BE209F.1000009@siege-engine.com> <55BE509B.2080307@yandex.ru> <55C166EF.9060909@gmail.com> <55CA54A3.1030104@yandex.ru> <55CA9808.4000809@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1439371707 26076 80.91.229.3 (12 Aug 2015 09:28:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Aug 2015 09:28:27 +0000 (UTC) To: Eric Ludlam , Emacs Development Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 12 11:28:22 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 1ZPSKc-0005hq-2z for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2015 11:28:22 +0200 Original-Received: from localhost ([::1]:37662 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPSKa-0007PV-Ve for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2015 05:28:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPSKV-0007N6-Iw for emacs-devel@gnu.org; Wed, 12 Aug 2015 05:28:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPSKS-0004o1-9u for emacs-devel@gnu.org; Wed, 12 Aug 2015 05:28:15 -0400 Original-Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:34516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPSKR-0004nu-SV for emacs-devel@gnu.org; Wed, 12 Aug 2015 05:28:12 -0400 Original-Received: by lbbtg9 with SMTP id tg9so6189075lbb.1 for ; Wed, 12 Aug 2015 02:28:11 -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=BKVIUtRFg3hKhAZ+ctKY22ngA1OCkMkqe03GDjtImCg=; b=X22vGdiohjObCFP45y6p49JIGgxZ0NtNi2hg7BR0HDsoTcGEUqQBljoy3xCw+19cV7 1F7MH2nnzxeQ/x9bX2xfZ9vX4y39JnnSs9jR3hlbP7/rmf1jQiAqqpT7tvUU1aCoUVeb 9oPTKxr/SzrKRZ/LqhLQ2ikWDhm8XiFVtqKdE4UZywqdZnJwoknw1Af6VQGVORPvWySK 1Bnc5b1loDnmyNCQLu8uPfJrrxBzFdt4EOzUymHk03tqJHlOLhAR0cpciVpc5YdYorKY Q6FF46C9GDKcJjSqQSiqNVRxPr1mFifL4yYH7XWy0gIigA/8NCeBp9KYS3M3VLxcHgtR Fq4A== X-Received: by 10.112.73.33 with SMTP id i1mr31513748lbv.31.1439371691086; Wed, 12 Aug 2015 02:28:11 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id n8sm1076910lah.43.2015.08.12.02.28.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2015 02:28:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <55CA9808.4000809@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::229 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:188750 Archived-At: On 08/12/2015 03:49 AM, Eric Ludlam wrote: > Every project is indeed different. A system that needs to load lisp > code needs to protect against ill formatted lisp code. Putting this in > a core system will help implementations from all creating the same > latent bug. If project.el isn't going to provide detection services, > then it won't need this feature. Probably not, at least not at first. > In EDE, a project adds itself to the list of possible projects. Each > project classifies itself by a term that places itself in one of three > bins, and hopefully those bins don't conflict. ;) Not to dismiss the detailed approach, but the user could reorder the elements in project-find-functions as well, if the default order is not to their liking. What you're describing would be an improvement, but not of the revolutionary kind. And I'm not really sure how to fit the classification together with project-find-functions. > Right. Each project implementation needs to update their data from the > file system their own way. If there are generic development menus, it > would be helpful for the user to have one way to update project meta > data regardless of which type of implementation is active. I'd rather user never had to do that at all. >> * "Project Local Variables" look very similar to project metadata. > > They are a type of meta data that let users provide extended behavior to > the project. That sounds fine in theory, but we need a more concrete application. Your Projectile example, for instance, would work just as well if it didn't set the "project local variables" via the project API, and just stored the information in its internal storage. > I will need to look at your search path concept more. Are there > multiple paths for different purposes? No, just this one. Adding other paths will need more justification. > Several of these tools have an 'update the current tags file' type mode > you can get at. I don't recall if I wrapped that up with a handy > function or not. That would be nice. But then you don't need any extra information about the current project to do that, just knowing how to find the file and/or call the tool. In that case, it shouldn't need anything new in the project API. Not even how to find the root, maybe (just use locate-dominating-file, especially when there are several tags files in the project). > The key concept is that a project is rarely just one single activity. > Usually there are doc activities, code activities, build system > activities. Some projects have Java activities, and native C++ > activities. All these different things are for a common goal, and often > there is a common lingo between them. I represent that lingo as 'tags' > in Semantic, and it enables you to 'copy' a tag which includes the meta > data around the name and 'paste' it into a buffer of a different > language. That sounds like it needs a parser to work well. xref tries to handle it as "identifier at point", but we'll have to see whether the different implementations will include context information in it (via text properties). > The only useful one there can turn a lisp tag into a texi > @defun block, but you could imagine a way to update your java native > methods bidirectionally. The project knows how to link these systems > together, such as finding the right doc for your Lisp code. For one thing, writing documentation separately from sources is an alien idea to me (and for other Ruby, Java or JS programmers, I think). So this kind of information may need to be exposed as an optional service. > Language specificity was key for me because of the way mode-local works, > and how each language had customized behavior for the parsing tools. I > tended to focus on language specific accurate behaviors, and not generic > potentially inaccurate features. For example, smart completion vs > dabbrevs. I like smart completion, but by tying it to projects we'd discount the less accurate implementations that are still useful. On the other hand, a package that implements project handling can add its own, accurate completion functions as well. > As noted somewhere, symref had a way of converting modes to patterns. I > had to ask around, but eventually got something pretty good. It didn't work well for Ruby files initially, so I had to add the respective entries to semantic-symref-filepattern-alist. I'm sure there are languages out there that are still not covered. > I'd be glad if I could stop maintaining parts of EDE because it became > part of some core system. It is still unclear to me where the > boundaries lie. I'm not sure where a patch would be helpful yet. My > hope is that my document would help you define the bounds of project.el > based in a set of terms we can both agree to. It would then be obvious > how I could help by donating pieces of EDE as needed. My understanding of EDE is if there are tools that would be worth porting, they would need to be rewritten on top of more general methods, and would probably need rethinking. > My recommendation for you is to perhaps not reply to individual > clarifications above, but perhaps define where you think project.el fits > into the whole using whatever you like from my doc, and that would help > us focus the conversation on the boundary, and not on random things I > invented that aren't close to the boundary. I'll try to do something like that in the foreseeable future. But really, from where I'm standing, the question is not how to decide the list of features, but how to implement each particular feature in a way that would make sense for as many project types as possible.