From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Llu=C3=ADs?= Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sun, 18 Oct 2015 20:21:45 +0200 Message-ID: <87fv18hwau.fsf@fimbulvetr.bsc.es> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445192546 17515 80.91.229.3 (18 Oct 2015 18:22:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2015 18:22:26 +0000 (UTC) Cc: Eric Ludlam , =?utf-8?Q?Przemys=C5=82aw?= Wojnowski , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 18 20:22:17 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 1Znsb2-0004K2-F8 for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 20:22:16 +0200 Original-Received: from localhost ([::1]:35086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Znsb1-0001UT-HZ for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 14:22:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Znsai-0001U2-Uw for emacs-devel@gnu.org; Sun, 18 Oct 2015 14:21:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Znsaf-0003wu-IN for emacs-devel@gnu.org; Sun, 18 Oct 2015 14:21:56 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:56412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Znsaf-0003wn-8d for emacs-devel@gnu.org; Sun, 18 Oct 2015 14:21:53 -0400 Original-Received: from localhost ([84.88.51.85]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MLvLE-1Zvbol0WyK-007jhe; Sun, 18 Oct 2015 20:21:47 +0200 Mail-Followup-To: Dmitry Gutov , =?utf-8?Q?Przemys=C5=82?= =?utf-8?Q?aw?= Wojnowski , Eric Ludlam , emacs-devel@gnu.org In-Reply-To: <5622D5A5.80801@yandex.ru> (Dmitry Gutov's message of "Sun, 18 Oct 2015 02:11:33 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Provags-ID: V03:K0:E47REmVezhsALnuk5JnUtGnAUf64qpetMumSX2EX7RoodFAkdGb Vt1K8de1i6TxQq+FVQZWQ99saoehHAIv7vR45PNpzw2ZDDpX9FeJJ2MRsT12gjyHGSySE+S mEa522tyriwZkxMX9C+e4OQYJfBfb0cHsR199DAXZMudKe1g0/fboUfLKAVEyb7zmQwWQs/ usYFbgq1q9MIg3T00Mtug== X-UI-Out-Filterresults: notjunk:1;V01:K0:ixjer31iaUI=:qvLc10HssLworYsHqQyXJk lpCUhqAhNnR/4yEwI62oD03c6oBG6Hm06t6HVbQ4QLmxnt6EczLj7v03x2ILjT4lKV1ygW6WE qF6S5hjmwl1Ab+DmZurIBHhE9PHjEzz+X9X4NwkmWCR2sEfz7Njluum+8hKy+Fm6MVYwbF/J8 j5uJdAWWniYr/V+4YJXU5wd4YVPW95fKZw/Zrjjotm3rbg0uvm9RdHZQJTb3TUviRkRHofvDS Yj/j7hZaI0wYkXcpWIwn5MM9jDGbm3nmKShUyPZbNOcinG8zau2rNgD2f7UQHZ8TgvtgPiOFj phA4kggh3vHeGbZnLsGO8cuH35HbkNvmZHaYK7j7vN/v/IPaPw2TIG4SGAC8yoR0ws7SCvO9s cfImqTfz688vfaQ6lDaiiTnQV63DsqfVv6mHvkz+SZ7opdkc4LS91QzAZJbP1fqq5Gs7tknCr FmLax3MF6NzrTuV5JwCLnYPiXqfxzmXVZxAo+pnx+JsIc9Zo2bUz2sm7Od1OU5HyHOKBk1j50 hzj50RTWh10jxvbmNiRNYDPUS6FYzCDXrN7Wv9AGrGZqx0yxbXqohGC7DB6IxEwyDHKbceS/j q0QfZnnpRf4vW5z78jKMaWRcD+MFwpOu/f3FJ/3WODeGpBD+6t7CJh4/72cL0rrKxVl5UG1AH cI1f6Ndts0qD75mzUOyRPOErnQj91PeKRxb7JroglC6uEoRPcxWWwwn/y+IGq41fywy+2hosg n+4lqIDUEcb7DlUbwWJrjM4ee0sQz+i2rfmlu0Bk5IB9CsFMSDnhii09SLeqRpW5ZPCqtrrJ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.21 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:191993 Archived-At: Dmitry Gutov writes: > On 10/17/2015 08:18 PM, Llu=C3=ADs wrote: >> I didn't think of the "find path" functionality, but it does seem to mak= e sense >> to fold it into the "root path" service type. > You mean "find search path", right? Another name if it is "include path",= and > that's different from the executable path. 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 specifi= c 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 t= op of the "find path" functionality. > I think I've formed an idea how separating it from the find-root(s) servi= ce > would be useful. Currently, we have this awkward project-search-path-func= tion, > which can be defined in a major mode (we want this kind of functionality = to be > major mode-providable). > But if it were a separate service, that would be tidier. Introduce > project-search-path-functions, which would take the current project as an > argument and return an object that contains the search path (and, as a bo= nus, > maybe knows how to resolve a relative import string). > Then ruby-mode won't have to define a separate project type. It'll just a= dd to > project-search-path-functions that checks that there is a Gemfile somewhe= re > above the current directory and below the project root, and use the infor= mation > from it. The fact that returned object can also resolve imports is nice, = because > I wasn't sure where to put that behavior. > In general, though, this might be problematic when a language L will simp= ly read > its search path from an environment variable, and doesn't require a prese= nce of > any "bundle" file. Does it provide its search-path to absolutely any proj= ect? We > might need a "list of project languages" accessor on the "root" service > instances. User-customizable, of course. 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 wor= king on. This can be the case for projects that contain code in multiple languag= es, so that each can be treated slightly differently. The question is thus, for example, how do we fit the major-mode variable in= to 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? If that sounds reasonable, then why not also account for the path of the cu= rrent file? The same project might have different file search paths for different files... >>> On the flip side, if there are no B implementations that can work with = the >>> currently detected R service r1, but there's a certain b2 in service-b-= functions >>> that would work with r2 (currently shadowed by r1), we may be missing o= ut. >>=20 >> Exactly. I started prototyping a few interfaces where all requests go th= rough >> the public interfaces. A project-type acts similarly to your "service lo= cator" >> link, and projects are simply a service locator that manage multiple >> project-type instances grouped by the project. > You mean different project-types are like entirely different collections = of > services? Why call them project-types at all? I'm lost. > Isn't a project a collection of services (of different service-types)? Both are collections of services. I was thinking of the project as a collec= tion of project-types too, so that you can combine multiple of them. [...] >> While prototyping it, I actually decided it makes sense to implement this >> functionality on the service-type. It should know how to merge results f= rom >> multiple services, and every service must declare what service-type it p= rovides. > How about we reframe the description in terms of hooks? service-type is a= hook > variable, services are elements in it. You can call the elements of a hoo= k in a > sequence until one returns non-nil, or you can call all of them and combi= ne. I was thinking of service-types as providing multiple methods (hook variabl= es), one per function it exposes. >>> Having to declare each combination of service-types that a project can = provide >>> still seems unnecessarily limiting (and tedious). But that's what proje= ct-types >>> would be for, right? >>=20 >> Exactly. My idea was that common project types would be written once dec= laring >> all the service types they provide and through what service >> implementations. > So, why? > Take a look at xref-find-regexp. It looks up the current project, takes i= ts > roots (service 1) and its search-path (service 2). If either of the servi= ces can > be undefined in the current project, what would xref-find-regexp be suppo= sed to > do? > And what is the use of several common project types? Could you give an ex= ample? Suppose you have project-type T1 that provides service 1 (S1) but not S2. A= s you said, xref-find-regexp will fail. Now, there can be some best-effort project-type T0 that provides a brain-de= ad 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 us= ing any well-known project type. Note that some other project-type might provide a more intelligent S2 that,= for example, takes information from a compilation database. >> I'm not sure I follow, but maybe I responded you on my previous paragrap= hs. > 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? >>> Next, suppose a project instance can tell whether it provides a "build = tool" >>> service. What does a "call build task" command does? Looks for the curr= ent >>> project and gives up if it doesn't provide the required service, or spe= cifically >>> asks the locator for a project implementation that does provide that se= rvice? >>=20 >> I'd say both. My idea is that all project-types provide an auto-detection >> function; given a path, tell me if it conforms to this project-type. > In Emacs parlance, a "path" is a list of directories (see exec-path or > compilation-search-path). > The call-build-type needs the build-tool service. What project-type does = it use, > and why? Suppose these three project-types: * project-type-scons * project-type-make * project-type-linux Each provides only the build-tool service, and you open a file from the lin= ux kernel. The type project-type-scons does not apply, but the other two do. I= f we can assign some priority to them, we will end up with project-type-linux. >> Then, if we >> do not know of any project instance for that path, build a new one that = contains >> instances of all project-types that match with it. > What if we already have a project instance for that directory, but it doe= sn't > provide that service? I'd say there's no way out of this one. What troubles me the most is nestin= g, where each sub-directory might need to behave differently (e.g., have files= for different programming languages). Would then each file or directory have a potentially different project instance? Or should the project abstraction account for different services on different paths? >>> [0] http://martinfowler.com/articles/injection.html#ADynamicServiceLoca= tor >>=20 >> Building a project from all matching project-types provides a clean solu= tion to >> this. But to be honest, I'm not sure if it makes much sense beyond takin= g a >> single auto-detected project type plus an optional overlaid project-type= that >> contains user customizations. > I don't think user customizations should be a project-type. Rather, they = can be > applied via .dir-locals.el, inside each service-type utility function. I'm still not sure about this one. >> For example, we could have a fallback "project-type-generic", a makefile= -based >> "project-type-make" and a very specific "project-type-linux". Should we = overlay >> all of them or just take the most "specific" one? (aka linux). > The one that comes first in the hook. Hook entries from minor modes usual= ly 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 possib= le directory. Thanks, Lluis --=20 "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth