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: Thu, 27 Feb 2014 20:08:30 +0100 Message-ID: <87bnxscr0x.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> <87ha7lcxki.fsf@wanadoo.es> <83ios0xwcv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393528134 32166 80.91.229.3 (27 Feb 2014 19:08:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2014 19:08:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 27 20:09:02 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 1WJ6KJ-0005RH-Gc for ged-emacs-devel@m.gmane.org; Thu, 27 Feb 2014 20:08:59 +0100 Original-Received: from localhost ([::1]:47481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ6KJ-0003rT-25 for ged-emacs-devel@m.gmane.org; Thu, 27 Feb 2014 14:08:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ6K9-0003qI-Sr for emacs-devel@gnu.org; Thu, 27 Feb 2014 14:08:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJ6K4-0004y9-0r for emacs-devel@gnu.org; Thu, 27 Feb 2014 14:08:49 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:48198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ6K3-0004y3-Mn for emacs-devel@gnu.org; Thu, 27 Feb 2014 14:08:43 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WJ6K1-00040K-Hk for emacs-devel@gnu.org; Thu, 27 Feb 2014 20:08:41 +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 ; Thu, 27 Feb 2014 20:08:41 +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 ; Thu, 27 Feb 2014 20:08:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 172 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:dSN4cxSZ2uvMsL/1pusyxiaU/oI= 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:169910 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. > > I don't know what exactly you tried, and why did you decide I was > doing unacceptable things, but what I actually tried was clang. After > adding the above line, it only shows one candidate, whereas I think it > should have shown 2. No. After adding your overload, there is just one candidate, namely, the one that exactly matches its argument type: char. > IMO, showing more candidates than strictly > necessary is a lesser evil than showing less than necessary. If this was an attempt of pointing to a defect on Clang, you failed, and it is not surprising, because Clang uses the same machinery for deciding the correct overload when it is acting as a compiler as when it is asked for completion candidates. Surely, if Clang failed to give the correct answer for the completion case, it would be a very broken C++ compiler too. >> > 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? > > Because you continue saying that nothing but clang is, or can be, good > enough. I'm saying that a compiler infraestructure, with the correct interfaces, makes any other approach look as a hack, for the reason stated on my previous paragraph. Right now only Clang fits the bill (possibly GCC too, modulo API convenience) but more compilers could qualify on the future. >> > 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. > > What basis do you have for this assertion? How many Emacs completion > packages that use clang did you try? There's only one that I could > find, and it has the following disclosure, which speaks for itself: > > Note that this minor mode isn't meant for serious use: it is meant > to help experiment with code completion based on Clang. > > Given such a small sample, I don't see how can anyone publish claims > such as yours. What are you trying to say with this? Does Clang's usefulness depend on whether or not an Emacs package exists? [snip] >> > If not recently, perhaps it got better since then? >> >> Surely it got better, but not enough, as demonstrated two messages ago. > > Nothing of the kind was demonstrated 2 messages ago. Are you serious? It failed on a case that could come from the first day of a course on C++ fundamentals. No complex expression type deduction, no template metaprogramming, no namespace resolution... it's C++ coming from the 1980s. Eli, are you a C++ programmer? Do you code in C++ on a regular basis? If you answer "no" to any of those questions, we'll better stop this discussion here and now. >> > 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. > > I think you have a different application in mind. In any case, > reiterating your opinion doesn't make it more credible, unless you back > that up by some specific evidence or data. > >> > 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? > > How about publishing your data, then? Which data? That CEDET doesn't know about overloads? They are very aware of that, as one of the maintainers acknowledged on this thread. > Perhaps CEDET developers can do > something with your bug reports, and then you will find a year from > now that things did change. Sorry, but this looks more like handwaving than real argumentation. I'm not the one who decided to work on a Elisp-based C++ code analysis tool. I'm the one who thinks that that enterprise has a limited range of applicability and there are other approaches with are much more promising. Why should I invest my time on CEDET? [snip] > This discussion _is_ about Emacs! It is not about parsing C++ for any > other purpose, or refactoring by other tools. Of course, knowledge of > available tools for Emacs is extremely relevant. If the tools were available, this discussion wouldn't arise. >> > 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++? > > Just enough to do its job, but no more. > > As another example, look at etags: it doesn't understand any language > it supports, and yet it generally does a very good job in finding the > identifiers. It is obvious that you don't understand the problem (well, it was obvious since the first time you suggested to implement the required functionality on Elisp all the way down). What Etags does is absolutely trivial compared to the required analysis for smart code completion, not to mention refactoring. [snip] >> A tool that fails on some cases is defective > > Then you will surely call Emacs "defective", because most if its > heuristics are not perfect. Here you go with all-or-nothing again. I can use Emacs for hours without facing any glitch. My experience with CEDET C++ code completion is that failure is the most likely outcome. Worse: while using it I need to direct my attention to checking that what CEDET suggests makes sense (when it manages to suggest something) and that makes me less productive even on the cases where CEDET gives the right answer. >> "cannot" is fundamentally different from "not allowed", if you are >> looking for the less-resistance path. > > Why would we be looking for the less-resistance path? It's not like > clang-using packages are queuing up for inclusion, Surely they will not queue for inclusion, because they all were rejected in advance. > it actually sounds > like they don't even exist yet. A perfect time for looking elsewhere > and finding a solution that will do its job reasonably well. No, a solution that fits RMS decision. Not to be confused with "doing the job well".