From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Mon, 12 Oct 2015 07:53:56 -0400 Message-ID: <561B9F54.4070108@siege-engine.com> References: <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <5618E51D.4070800@yandex.ru> <83twpzrp05.fsf@gnu.org> <5618ED93.8000001@yandex.ru> <83lhbbrnn7.fsf@gnu.org> <56191EBE.5050404@yandex.ru> <83612essaw.fsf@gnu.org> <877fmuix68.fsf@isaac.fritz.box> <8337xispn2.fsf@gnu.org> <56195055.6010409@gmx.at> <56198BC3.2080402@siege-engine.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1444651543 17625 80.91.229.3 (12 Oct 2015 12:05:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 12:05:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 14:05:35 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 1ZlbrA-0004vk-7b for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 14:05:32 +0200 Original-Received: from localhost ([::1]:54814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlbjz-0004H0-L8 for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 07:58:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlbg3-0007RY-Ul for emacs-devel@gnu.org; Mon, 12 Oct 2015 07:54:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zlbfy-0007jy-Vl for emacs-devel@gnu.org; Mon, 12 Oct 2015 07:54:03 -0400 Original-Received: from mail-qg0-f52.google.com ([209.85.192.52]:36326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlbfy-0007jo-SH for emacs-devel@gnu.org; Mon, 12 Oct 2015 07:53:58 -0400 Original-Received: by qgx61 with SMTP id 61so117795660qgx.3 for ; Mon, 12 Oct 2015 04:53:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=cjWv7RnDTpALi3RIcwwMArHKQsjT+lNKUvejs94bfp8=; b=ckteaySL7uqgjflDmOzhWjtq+djKmvOILjj4pHQ5zdOWtBRPscDXx6druw03vGIa+J mTODbkPeBXSAvGovqVpSzN8kkZBR/sZxZNVzUO7ddDmQZo9BFnwwoRjGprco/Cx2gPj5 D9X/vx5gD0eikwStivOFWzSecEWxoXLZVL852I5LPxQ/sf/H/YbuZ+o6fQXkhNIFX9G5 /Jvl5zI0qsodeFnI1yGPHurRTt/lZnTTrfPYO0zdOUkY4JA10jnYVjgHcHYCnvkJmVNC mzJMdk9LXmuIlZ8lZosrrzhyH7fvoQljuVvcErnBrgQasUgAQEb2jErK80LlHxpxAk2E pIVg== X-Received: by 10.140.235.212 with SMTP id g203mr32820686qhc.47.1444650838474; Mon, 12 Oct 2015 04:53:58 -0700 (PDT) Original-Received: from [192.168.1.202] (pool-71-184-198-118.bstnma.fios.verizon.net. [71.184.198.118]) by smtp.googlemail.com with ESMTPSA id j193sm6946682qhc.17.2015.10.12.04.53.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 04:53:57 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.192.52 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:191322 Archived-At: On 10/10/2015 07:20 PM, John Wiegley wrote: >>>>>> Eric Ludlam writes: > >> In CEDET, the function / command `semantic-analyze-current-context' provides >> an output that has lots of details about the buffer near point. Not just >> what the cursor is on, but if it is a chain of symbols such as dereferencing >> struct pointers, and in many cases, it figures out the data type of the >> symbol the cursor is on. It also handles in-buffer caching, etc and plenty >> of performance tweaking is available. > > My preference is for each core feature to have an extremely simple and light > interface (taking indentation as an ideal), so that it can also be used for > non-IDE tasks we haven't imagined yet. From what I know about CEDET to date, > it is much more complex than this objective. That is because the task is complex. > When I squint, I see ctags, imenu, pcomplete, helm, company, hippie-expand, > flycheck, and more, all starting to look somewhat alike: They each act upon > information relevant to the buffer in some way. Where they differ is in how > they derive this information, and how the user interacts with it. Can we > provide a common, low-level interface for this style of functionality? A > common API against which we can implement both data-gathering backends, and > display front-ends? And with an emphasis on efficiency and low-latency! The primary difference between your list and CEDET is that those other tools focus on picking up a current symbol, or perhaps a substring, and it is up to the next layer to figure out more about it. I agree that that could be simplified across the variosu tools, but AFAIK the 'thing-at-pt' stuff is that common interface. IDEs know more about the buffer than just some symbol and the major-mode of the current buffer. Things like dabbrev work pretty well finding similar strings that often have the feel of being 'smart', but that only works if you've typed it in before. If you want a stronger set of smart behaviours at point, you will need to raise your standard to include more derived data. > We need to harness the power of multiplication, so that every new backend > makes every frontend automatically more powerful, and vice versa. This will > also help us better leverage our existing base of contributors. This I agree with. Eric