From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Tue, 27 Oct 2015 00:40:36 +0100 Message-ID: <87twpdmc5n.fsf@wanadoo.es> References: <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <561A6199.1020901@cumego.com> <561B9D87.70504@yandex.ru> <87vb9wcpw9.fsf@esperi.org.uk> <83eggkwdgh.fsf@gnu.org> <83611ww5uc.fsf@gnu.org> <83si4xbi2m.fsf@gnu.org> <878u6pcs74.fsf@igel.home> <83io5tbcye.fsf@gnu.org> <87bnblnzn7.fsf@wanadoo.es> <562E8E51.40006@yandex.ru> <877fm9nuxv.fsf@wanadoo.es> <562EACD9.1030807@yandex.ru> <87y4epmdpr.fsf@wanadoo.es> <562EB516.502@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445902874 12680 80.91.229.3 (26 Oct 2015 23:41:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Oct 2015 23:41:14 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 27 00:41: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 1ZqrNy-0000OR-C2 for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 00:41:06 +0100 Original-Received: from localhost ([::1]:55907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqrNx-00056g-H2 for ged-emacs-devel@m.gmane.org; Mon, 26 Oct 2015 19:41:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqrNg-00056a-OG for emacs-devel@gnu.org; Mon, 26 Oct 2015 19:40:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqrNd-0004d6-6e for emacs-devel@gnu.org; Mon, 26 Oct 2015 19:40:48 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:39669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqrNc-0004cT-Pl for emacs-devel@gnu.org; Mon, 26 Oct 2015 19:40:45 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZqrNb-0008Lr-9d for emacs-devel@gnu.org; Tue, 27 Oct 2015 00:40:43 +0100 Original-Received: from 157.red-81-44-103.dynamicip.rima-tde.net ([81.44.103.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Oct 2015 00:40:43 +0100 Original-Received: from ofv by 157.red-81-44-103.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Oct 2015 00:40:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 37 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 157.red-81-44-103.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:bGUGIJcey7P/4mKSCSxo3IAExQ0= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:192697 Archived-At: Dmitry Gutov writes: [snip] >> Definitions can be tricky in C++, if you wish to distinguish the case >> where multiple namespaces or classes defines the same keyword and you >> expect from Emacs to jump to the correct definition, deduces from the >> context. In that case you need a parser that is good enough to act as a >> compiler front-end. > > "jump to definition" is about accurately recognizing references. But > if you're jumping to foo.bar(), and Emacs doesn't know the type of > 'foo', at least it can show you the definitions of all methods named > 'bar', and you'll be able to choose for yourself. Using etags-select, > for instance. For not-so-big C++ projects, that can be as useless as displaying all the uses of "bar" on the code base. >> Trying to find a common ground on current use cases is difficult enough. >> Anticipating future requirements is almost impossible. Good luck with >> that. > > That's defeatism. Doesn't it bother you that every third-party package > uses a (sometimes subtly) different set of key bindings, and a > different way to present the same kinds of information (definitions, > references, documentation, etc)? If there is a common pattern, by all means, implement it (on a way that provides for those subtle differences when they make sense.) But those packages still need to maintain compatibility with older Emacsen. Distributing the library on GNU ELPA instead of the Emacs core would make things better for the external packages, though. But then, what's the difference from developing the library outside of Emacs core and working directly with the authors of those external packages? If the library or API is developed on emacs-devel, is it acceptable to design it by the requirements of rtags, for instance?