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: Emacs contributions, C and Lisp Date: Wed, 26 Feb 2014 23:34:53 +0100 Message-ID: <87ha7lcxki.fsf@wanadoo.es> References: <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <87y50z90pd.fsf@fencepost.gnu.org> <87txbn8r6x.fsf@fencepost.gnu.org> <8338j717oe.fsf@gnu.org> <87zjlf6tdx.fsf@fencepost.gnu.org> <83sir7yue7.fsf@gnu.org> <8761o3dlak.fsf@wanadoo.es> <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <834n3lzux6.fsf@gnu.org> <87ppm9d3y4.fsf@wanadoo.es> <83ob1ty4qr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393454122 10820 80.91.229.3 (26 Feb 2014 22:35:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2014 22:35:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 26 23:35:30 2014 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 1WIn4W-0008Cb-4U for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 23:35:24 +0100 Original-Received: from localhost ([::1]:43547 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIn4V-0004F6-Nn for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 17:35:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIn4N-00042q-6r for emacs-devel@gnu.org; Wed, 26 Feb 2014 17:35:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIn4E-00084P-E7 for emacs-devel@gnu.org; Wed, 26 Feb 2014 17:35:15 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:54864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIn4E-00082n-51 for emacs-devel@gnu.org; Wed, 26 Feb 2014 17:35:06 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WIn4C-0006bd-Rr for emacs-devel@gnu.org; Wed, 26 Feb 2014 23:35:04 +0100 Original-Received: from 19.red-83-39-162.dynamicip.rima-tde.net ([83.39.162.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Feb 2014 23:35:04 +0100 Original-Received: from ofv by 19.red-83-39-162.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Feb 2014 23:35:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 144 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 19.red-83-39-162.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:X5G68+zSpupNzyLM/0MJ6chKEAQ= 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:169899 Archived-At: Eli Zaretskii writes: >> > And what happens if you add >> > >> > B baz(char); >> > >> > to the above -- will it show 2 candidates or just one? >> >> Dunno. > > I suggest to try (I did). Maybe then you will be less radical in your > judgment of having N+1 candidates when only N are strictly needed. Adding an overload to just make an specific case work on certain completion package is unacceptable, to say it mildly. >> As David Engster explained, CEDET does the simplest thing (take >> one of the overloads and ignore the rest.) > > I see nothing wrong with doing the simplest thing, if it gives > reasonable results. This is an engineering discipline, not an exact > science; compromises are our bread and butter. I'm sure you are well > aware of that. Yes, I'm aware of that. That's the reason why when I re-try CEDET every year, I use it on the most simple parts of my code and then decide that it is not mature enough for even that usage. [Lurker: CEDET can be productive when your code is simple enough (or if you have a high tolerance to completion failures.) There is plenty of C++ code like that out there, so don't be discouraged by my experience and try it yourself.] > So I don't quite understand why you decided (without trying) that none > of the existing solutions can be extended to fit the bill. How do you know that I didn't tried? > Are you seriously claiming that clang is the _only_ way to go? I hope > not. On terms of reduced effort, it is the easiest way by far. >> > ECB also supports mart completion. >> >> For C++? Not really. > > How do you know? When did you last try? A few hours ago, as described on this very same sub-thread. See above, you can see a test case where it fails and you discussed it. Apart from that, I try it every year or so. What makes you think that I'm talking about CEDET without having experience with it? > If not recently, perhaps it got better since then? Surely it got better, but not enough, as demonstrated two messages ago. > Did you attempt to analyze what is missing and > how hard would it be to add that? I'm no compiler expert, but as stated multiple times by now, for expecting CEDET to work on modern C++ code bases the required effort is *huge*. And that's suppossing you are a compiler writer with experience implementing C++ front-ends. > Who said it was slow _today_? I found complaints from 2009, are you > really going to claim they are still relevant, without checking out? Again, why do you assume that I didn't tried? IIRC last time I seriously tried CEDET (a year ago) it was fast enough (although it missed/confused most symbols) on my projects, which are on the tens of thousands of lines (whithout external libraries). There was a perceivable lag on each completion request while working on a destktop-class machine. Other C++ projects which I tinker with are two orders of magnitude larger than that. But the important point here is that the most time-consuming analysis features seem missing from CEDET. >> > The only Emacs package for this that I could find is proprietary >> > (Xrefactory). Do you happen to know about any free ones? >> >> No. My knowledge is far from exhaustive, though. > > Then perhaps the assertiveness of your opinions should be on par with > how much you know. What are you talking about? What relevance has on this discussion my knowledge of available tools for Emacs? > Statistics doesn't understand anything about the underlying phenomena, > and yet it is able to produce very useful results. IOW, we don't need > to understand C++, we just need to be able to do certain jobs. > Understanding (parts of) it is the means to an end, and that's all. A C++ source code analysis tool has no need to understand C++? >> >> IIRC I already told you this a few weeks ago, but I'll repeat: a C++ >> >> front-end (even without code generation capabilities) requires an >> >> immense amount of work from highly specialized people, and then needs >> >> improvements as new standards are published. >> > >> > Only if you need to be 110% accurate, >> >> Since 100% is perfect, why should I wish more? ;-) > > I don't know, you tell me. I detect a tendency to hyperbole and all-or-nothing argumentation on your messages. In this case, my emphasis on accurate results is represented by you as a 110% requirement. This is not constructive. >> > which is certainly a requirement >> > for a compiler. But we don't need such strict requirements for the >> > features we are discussing, I think. >> >> A defective refactoring tool can easily cause more work than it saves. >> It can introduce subtle bugs, too. > > "Defective" is a far cry from "non-strict requirements", don't you > think? A tool that fails on some cases is defective, unless you described its shortcomings and advertised that it doesn't work on C++, but on a subset of the language. It is true that it is unreasonable to expect correct behavior on concocted cases or even the rare ones, but anything less than that is a defect. >> >> "we cannot" isn't the right expression. "we are not allowed" is the >> >> correct description. >> > >> > I'm trying to keep this part of the thread out of politics and into >> > something that could hopefully lead to a working implementation. >> >> I'm not interested on politics either. I just wanted to be accurate :-) > > To what end? "cannot" is fundamentally different from "not allowed", if you are looking for the less-resistance path.