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: Mon, 19 Oct 2015 15:04:37 +0200 Message-ID: <87mvvff1qy.fsf@fimbulvetr.bsc.es> References: <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> <562410AD.2020204@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 1445259918 24363 80.91.229.3 (19 Oct 2015 13:05:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 13:05:18 +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 Mon Oct 19 15:05:07 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 1ZoA7a-0003qd-R3 for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 15:05:03 +0200 Original-Received: from localhost ([::1]:39374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoA7a-00084n-4u for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 09:05:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoA7R-0007xR-OF for emacs-devel@gnu.org; Mon, 19 Oct 2015 09:04:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoA7L-000563-C5 for emacs-devel@gnu.org; Mon, 19 Oct 2015 09:04:53 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:64129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoA7L-00055s-3V for emacs-devel@gnu.org; Mon, 19 Oct 2015 09:04:47 -0400 Original-Received: from localhost ([84.88.51.85]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lrek1-1aXI4p4Aaj-013NbX; Mon, 19 Oct 2015 15:04:39 +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: <562410AD.2020204@yandex.ru> (Dmitry Gutov's message of "Mon, 19 Oct 2015 00:35:41 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Provags-ID: V03:K0:w23+z8zRYDqh4NNjeeRGqVnTTlRhRyklwp5RNbE4UrfzF0dAUQd I1IqFMNbGRk9Cd9zbhiwZSXKzGRj21KCoo6QSjsrrPX7W+7v91qNto/CXZMHAbiOo+TUrGP 0+G44a+l1o7itUKRQKiIbYsnx64SoSH47dHWHjV4yqZNxTv5Z8SlUYYjFEcBs/ASDDKzJ/n loZbHBedvDb2nmEuy+S1A== X-UI-Out-Filterresults: notjunk:1;V01:K0:E1k+O1/woOY=:IMZxQIVD5TfoCi0PiiyA8C PPIiSc4fyv95yjIu+FCsli9HmNnISmo+bkstn0X14GDcxahEFYK6QpDglot1UZTJSrmT3iVSq oJP0GBmZ77ClEhYV+V8KqqTZhOk9eZcFwpIMuhwcDXwX8LOT50kbIDqf7wmWZ6kIPU7x+8FHk Ct0QSZs38Yv/CQJal5CiSgVrb6V1tt4dy1HkI4Kd8pbNrejwus9hrHLKY/yGjHvdrNQdAfUFp 9JiACILKysjk20LkSGN+7a8oY9vuIAB/dUlfNXxZGPCPK8RdaVxGr60s2DkL3oRTOpbQcTH/z eFAgUiaENV3NXboybvvWakXiG4wfoJFVwYeiK2OC8gTJTq0jEo89Q7EOv56nRQpe1rIGaqE00 z547rw29sHLmjBnLf0Q/vV+w7MAn9mghM2xcAAeYVlWHUbP67oTkOZefSatvq7tDptKHSf/mj CukxB/KWpi97jINlIitXe+m16NvQDHA54eB/qJwTJwE2cqo0Az/rB1knDR7rK12AQ3ufvcvjl hxBdxcxHymKOtnLz+VZkjcOt9PU1cMgyBsZVFKAm8aq5U26K3N7+M8LEPVdWjLaz37wOe/Vtx hUuQGCUYSzNqc+1p1qW3LmpPSmPif9SISoHau9NWKT27zK75czxXLBhbJj+aLjcb8fOQNBax8 /bbR0SM5pNRiSC7BGCDGsTQPRQfDaXdSbaJEfxAx7QAdh0xZLZ7nWId2n0I/wbIlQJfpwFgge akHec68xTggs4xG6rttZ2JRREUojGLUq8Eezb7sLM6oB1n7ysW/5D2g41b4zg/UDQ4/19yZW X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.18 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:192085 Archived-At: Dmitry Gutov writes: > On 10/18/2015 09:21 PM, Llu=C3=ADs wrote: [...] >> 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 differ= ent >> files... > Yes. Add the "directory" parameter (or pass it implicitly by binding > `default-directory')? The list is getting longer... That's the point I wanted to raise. How flexible should the underlying infrastructure be? And based on what should it be flexible? >> I was thinking of service-types as providing multiple methods (hook vari= ables), >> one per function it exposes. > Nothing can contain multiple hook variables. Hook variables are global. T= he > values returned from them, however, could define several methods. I think I did not explain myself well. I meant having one hook variable for= each public method of each service type. >> 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 b= e a > tricky configuration a user would have to perform in a file inside the ro= ot > directory of each of their projects? If every project-type T* has a probing function that tells you if it's applicable to your current project, then you simply overlay all project typ= es that match (or support) your project. IMHO, how to expose this to the user is a question that needs answering lat= er [...] >>> How would a random command that needs certain info from services x, y a= nd z, use >>> this API? >>=20 >> 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-functio= ns 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), b= ut > that's of no interest to the API. Ok, so the first time you call `project-current', the system can check all project-types it knows about and see which ones apply to your file. From th= at a project object object is created overlaying the matched project-types. Next= time you request `project-current' a cached value can be returned, or maybe look= ing at the value of some parent directory. >> What troubles me the most is nesting, >> where each sub-directory might need to behave differently (e.g., have fi= les for >> different programming languages). > I worry more about directories with files for different programming langu= ages > 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 com= bine > 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 director= ies > inside a project. Otherwise, we'd get different results for commands call= ed from > different directories, sometimes with no apparent reason. > Still unsure about it. Ok, so it seems that we have two kinds of operations: * global: an operation that behaves the same regardless of where you're performing the request from * local: an operation that can behave differently depending on the path you= 're performing the request from, depending on the major-mode, depending on so= me environment variable, or depending on some other arbitrary condition Would it ever make sense for a service method to provide both kinds of operations? (i.e., discriminate through an argument) >>> The one that comes first in the hook. Hook entries from minor modes usu= ally come >>> before the hook entries from major modes, and it's user's responsibilit= y not to >>> enable several minor modes at once that share the same responsibility. >>=20 >> 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 pos= sible >> directory. > How would having numeric priorities help? They'd still be static and appl= y 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. That's true, the user always needs some "backdoor" to customize behavior, s= ince there's no global behavior that can fit all cases. Cheers, 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