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: IDE Date: Mon, 19 Oct 2015 00:35:41 +0300 Message-ID: <562410AD.2020204@yandex.ru> References: <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <561A6199.1020901@cumego.com> <561B9D87.70504@yandex.ru> <561C2C17.3090503@cumego.com> <561DC1CA.6090901@siege-engine.com> <561E3FB6.8010407@yandex.ru> <561EEFDE.7000809@gmail.com> <561F29D0.3070605@yandex.ru> <561FA79C.30207@gmail.com> <56200D07.30206@yandex.ru> <5620A99E.7080009@cumego.com> <5620D109.2010006@yandex.ru> <5620DCCD.8030809@cumego.com> <87y4f2u5ef.fsf@fimbulvetr.bsc.es> <5621C701.5030608@yandex.ru> <87d1wdo1la.fsf@fimbulvetr.bsc.es> <5622D5A5.80801@yandex.ru> <87fv18hwau.fsf@fimbulvetr.bsc.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1445204166 16801 80.91.229.3 (18 Oct 2015 21:36:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2015 21:36:06 +0000 (UTC) To: =?UTF-8?Q?Przemys=c5=82aw_Wojnowski?= , Eric Ludlam , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 18 23:35:55 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 1ZnvcP-00035n-Sw for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 23:35:54 +0200 Original-Received: from localhost ([::1]:35614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnvcO-0007Sh-HK for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 17:35:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnvcK-0007Sc-JH for emacs-devel@gnu.org; Sun, 18 Oct 2015 17:35:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnvcH-00018S-OT for emacs-devel@gnu.org; Sun, 18 Oct 2015 17:35:48 -0400 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:34577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnvcH-00018N-FZ for emacs-devel@gnu.org; Sun, 18 Oct 2015 17:35:45 -0400 Original-Received: by wikq8 with SMTP id q8so27000261wik.1 for ; Sun, 18 Oct 2015 14:35:44 -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=3pYlhzQUu1t0Gic+pfFuiqg2oODaipzhU5204EKqsAc=; b=qs2Cv987l9DOpjFppRJzk+iC1F2iAY6f7OjK1lA+G+RQbp00X5ExQQlLSfHZSPwVae UwDw/wGPrg/zl48od23bREy4LTLyKmKuhuKBrqGcTh9gg6CFjh2Kycc8xOPUYfEvA712 D3lAE47okMdkBFx41agVUIjkQf7ZhJxM87rLERprkjhd3LQ8wXguJYg6gHqQlk31G8Bc bLU/Kmmvc/hNVbqINxlGnjznXvfhisoZHYb9EEa9KqIkIJg7H7DGWle4+JWFSqUBX2nC XTdgKLsiykxGEwIufQZHQfAYaSGBGMU8uOprg3bIFXPs8avsvcbjp8Z/Puop0u80dN11 RKmQ== X-Received: by 10.180.105.234 with SMTP id gp10mr15634974wib.51.1445204144875; Sun, 18 Oct 2015 14:35:44 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id lv4sm36213338wjb.43.2015.10.18.14.35.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 14:35:43 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <87fv18hwau.fsf@fimbulvetr.bsc.es> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::230 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:192016 Archived-At: On 10/18/2015 09:21 PM, Lluís wrote: > No, I mean something as simple as concatenating the project's root with a > non-absolute path given as an argument. Search or include paths are specific to > the organization of the project at hand (e.g., on a C project not every > directory should be searched for an include), but could be implemented on top of > the "find path" functionality. Then, UUIC, maybe that would be called "find relative path". Similar to https://atom.io/docs/api/v1.0.19/Project#instance-relativizePath > That's one of my concerns with the project concept. As you pointed out, > behaviour can change, for example, based on the mode of the file you're working > on. This can be the case for projects that contain code in multiple languages, > so that each can be treated slightly differently. We can't rely on the current file being the deciding factor, however. At least some users would expect that if we're in a given project (say, in an open Dired buffer, or in a YAML config, or in a Compilation buffer), and the project contains Ruby files, the search for references to `each' would still use the Ruby search path. > The question is thus, for example, how do we fit the major-mode variable into > this scheme? The problem becomes multi-dimensional, and I'm not sure how to > specify that. Should some service-types be dependant on the major-mode, such > that a project can have mutiple services for the same type but for different > major-modes? The language can be passed as a second argument to project-search-path-functions elements. But then the project would need to know the set of languages to pass in. As long as we prohibit search-path from depending on the current buffer, any parameters need to passed in explicitly (except one, see below). > If that sounds reasonable, then why not also account for the path of the current > file? The same project might have different file search paths for different > files... Yes. Add the "directory" parameter (or pass it implicitly by binding `default-directory')? The list is getting longer... > I was thinking of service-types as providing multiple methods (hook variables), > one per function it exposes. Nothing can contain multiple hook variables. Hook variables are global. The values returned from them, however, could define several methods. > Now, there can be some best-effort project-type T0 that provides a brain-dead S2 > that looks at all sub-directories. If you create your project overlaying T0 and > T1, you can always get some best-effort functionality in case you're not using > any well-known project type. At which point does a project become "overlaying" T0 and T1? Would that be a tricky configuration a user would have to perform in a file inside the root directory of each of their projects? > Note that some other project-type might provide a more intelligent S2 that, for > example, takes information from a compilation database. Right. >> How would a random command that needs certain info from services x, y and z, use >> this API? > > Does the previous paragraph answer it now? Not really. I "create" a project? Could you rephrase that in terms of the project.el API? Here's an example: the command calls `project-current', which returns the current detected value of project. Then it passes it to `project-current-search-path', which consults project-search-path-functions and returns an object describing the search-path, which the command uses with another method. Something will "create" a project (the user, somehow, or a minor mode), but that's of no interest to the API. > What troubles me the most is nesting, > where each sub-directory might need to behave differently (e.g., have files for > different programming languages). I worry more about directories with files for different programming languages all inside them. At some point, some code will either have to prompt the user, guess somehow, or ask for search-path for all the languages, and then combine the results. > Would then each file or directory have a > potentially different project instance? Or should the project abstraction > account for different services on different paths? Maybe we should decide that search-path must be the same for all directories inside a project. Otherwise, we'd get different results for commands called from different directories, sometimes with no apparent reason. Still unsure about it. >> The one that comes first in the hook. Hook entries from minor modes usually come >> before the hook entries from major modes, and it's user's responsibility not to >> enable several minor modes at once that share the same responsibility. > > I'd prefer the system to be able to auto-detect the proper type whenever > possible, instead of relying on the user establishing order for each possible > directory. How would having numeric priorities help? They'd still be static and apply to all directories. Also note that for project types supplied for Emacs, we'd be able to put them into hooks in the proper order. With third-party code, however, the order might be wrong sometimes, but we also have no guarantee that their authors would assign correct priorities.