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: Tue, 20 Oct 2015 03:45:58 +0300 Message-ID: <56258EC6.7090706@yandex.ru> 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> <87mvvff1qy.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 1445301984 22541 80.91.229.3 (20 Oct 2015 00:46:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Oct 2015 00:46:24 +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 Tue Oct 20 02:46:20 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 1ZoL4F-0008Mq-5L for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 02:46:19 +0200 Original-Received: from localhost ([::1]:42722 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoL4E-0001Vl-6G for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 20:46:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoL40-0001VS-Vn for emacs-devel@gnu.org; Mon, 19 Oct 2015 20:46:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoL3x-00016C-Pj for emacs-devel@gnu.org; Mon, 19 Oct 2015 20:46:04 -0400 Original-Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:37142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoL3x-000168-HL for emacs-devel@gnu.org; Mon, 19 Oct 2015 20:46:01 -0400 Original-Received: by wicfv8 with SMTP id fv8so5581896wic.0 for ; Mon, 19 Oct 2015 17:46:00 -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=Vh0LftlA6FQq3PQH0Ur/QwXH+syOL2LCYzHjvnTYTjU=; b=hezNHaGhhJGbthCjDEDzoJl4AdLpolVf7yDtdfcFUiv2P2wve+gLahBJHKpAe3qqqL yDipIQd4dUyo7M/OwBG+lP+F41r+3dNztG6oF5JpnOaAiWDjo9eE1jtl5OeW//uTrVMs /HytWTQq28D1p1M4F3+Aaj+WOGCYHu8XwTjsd2OKed+BmugVEN+ojGPo9hjP8lOedFxC jZspV84B1mak0B8HTVrdqMvfylOZBwE8fSApevpEK/w/U8e9tflBz+k1+odPZuJ+pa4n ARO0hbNlVcyyxOQPG8Cr3T+aIJo/EbcQXyl0t+FOgM3kLSw2dSGUhpXYnsxGa6hM3wva /a2g== X-Received: by 10.194.8.227 with SMTP id u3mr343682wja.38.1445301960871; Mon, 19 Oct 2015 17:46:00 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id lb10sm427714wjc.9.2015.10.19.17.45.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Oct 2015 17:45:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <87mvvff1qy.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::22f 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:192136 Archived-At: On 10/19/2015 04:04 PM, Lluís wrote: > That's the point I wanted to raise. How flexible should the underlying > infrastructure be? And based on what should it be flexible? Well, yeah. These are the practical questions, decisions on which will shape the result. Having limitations isn't bad, as long as the user will still be able to enjoy useful behavior, one way or another. Option one: we allow search-path to depend on default-directory (in addition to the current project). Then the user can employ VC as a backend for projects, and yet have several different applications inside that repository. I'm describing this on the basis of one of the projects we have at work. Option two: we disallow search-path depending on default-directory. Then, for the same project, VC can't be the backend, and the "project" will have to be split into several (VC can't be used as a backend heere). Which will make at least as much sense. It will require a special project type for Ruby, based on the presence of Gemfile. > I think I did not explain myself well. I meant having one hook variable for each > public method of each service type. Why aggregate them into service types, then? Just call each "public method" (or hook) a separate service. > 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 types > that match (or support) your project. > > IMHO, how to expose this to the user is a question that needs answering later The "overlaying" process would also need some explanation. And consideration. Suppose there are several implementations of the same service-type, and the results they return (like search-path elements) overlap. How would you produce the resulting list? (delete-dups (apply #'append ...))? That would assume that there can't be "bad" (less precise) elements. For the "find references" service (if we had one), you would want to only keep the precise results, if available, a not mash them together with the output of Grep. > 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 that 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 looking > at the value of some parent directory. Caching is incidental. And I still don't know what "overlaying" is. In solid details, I mean. > 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 some > 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) It might. The "find included file" operation would probably want to consider the type of the current file. The environment variable can be looked up from the service itself. Arbitrary conditions are fine, as long they're not dependent on the current buffer too much. > That's true, the user always needs some "backdoor" to customize behavior, since > there's no global behavior that can fit all cases. The user would always be able to rearrange the elements in a hook, or add their own function (service implementation), maybe composing existing ones.