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: Sat, 10 Oct 2015 18:05:55 -0400 Message-ID: <56198BC3.2080402@siege-engine.com> References: <831td9z18h.fsf@gnu.org> <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> 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 1444514784 10226 80.91.229.3 (10 Oct 2015 22:06:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 22:06:24 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 11 00:06:15 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 1Zl2HN-00033n-KY for ged-emacs-devel@m.gmane.org; Sun, 11 Oct 2015 00:06:13 +0200 Original-Received: from localhost ([::1]:46525 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl2HM-0004BF-Sf for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 18:06:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl2HA-0004B7-Jc for emacs-devel@gnu.org; Sat, 10 Oct 2015 18:06:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zl2H7-00014x-EX for emacs-devel@gnu.org; Sat, 10 Oct 2015 18:06:00 -0400 Original-Received: from mail-qk0-f173.google.com ([209.85.220.173]:35531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl2H7-00014t-AJ for emacs-devel@gnu.org; Sat, 10 Oct 2015 18:05:57 -0400 Original-Received: by qkap81 with SMTP id p81so46280935qka.2 for ; Sat, 10 Oct 2015 15:05:57 -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=cCHC28GZMGUDvOW65FUS3I5XZxK7iC0rHnkEwbnDuh8=; b=kUrFeXo9FbaKVrBkNtHMF6NSAAtV4aGKN/iqPEOFUMhWHKBQ+Id10V6vXkAeRe6kS9 PnvRJgX4NcL9TqiTWMlxXzVBlG5pR1cPp9tLpdO3K7kQuNZAgAokmw8gQQkZf0nDsach uDBHgdfdjntb9tfP8T7Yx05VMBt0a679bsK2PH3MHVs+oefv6vkZiQT5+Xk1eQjOwfyd KJboIZdALgKqYZEmELGt1GBh0r4yFbFij1Exi7aXXT+Rf22DmxxPu4SKXGFlwjCvHi70 chkEk5n8Rz24j6Sw2yjRjNWeSodiKLSdHmAmL0aHvnKSDTJ9njM1JUQUyji2kitJbvhI lQqQ== X-Received: by 10.55.200.144 with SMTP id t16mr15938343qkl.0.1444514756979; Sat, 10 Oct 2015 15:05:56 -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 145sm3735875qhb.20.2015.10.10.15.05.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Oct 2015 15:05:56 -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.220.173 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:191181 Archived-At: On 10/10/2015 02:31 PM, John Wiegley wrote: > If we have a single paradigm for "determining interesting details about the > buffer, and near point", with the ability to refine the query based on what is > need, optionally cache results, etc., then the competing libraries we have > today could share functionality. The present day `all-completions` function is > too spare to fit this bill, so it's less of an IDE feature in my book and more > just a Lisp library function. 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. This is independent of the functions that perform completions. Eric