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 21:17:07 +0100 Message-ID: <87ppm9d3y4.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393445852 10551 80.91.229.3 (26 Feb 2014 20:17:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2014 20:17:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 26 21:17:40 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 1WIkvC-0006gc-TQ for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 21:17:39 +0100 Original-Received: from localhost ([::1]:43092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIkvC-00042a-E7 for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 15:17:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIkv3-00040M-Pu for emacs-devel@gnu.org; Wed, 26 Feb 2014 15:17:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIkux-0005wM-65 for emacs-devel@gnu.org; Wed, 26 Feb 2014 15:17:29 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:50068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIkuw-0005wE-Se for emacs-devel@gnu.org; Wed, 26 Feb 2014 15:17:23 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WIkut-0005Tn-QB for emacs-devel@gnu.org; Wed, 26 Feb 2014 21:17:19 +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 21:17:19 +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 21:17:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 104 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:7+pgqaySh7cBJBGsCZVG6w37s1Y= 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:169892 Archived-At: Eli Zaretskii writes: > Would it be so bad if it showed 2 candidates instead of one? IMO, yes. The "smart" part of "smart completion" is that only suitable candidates are shown. Something else just causes confusion and compile-edit cycles. Also, that example used a method for each class. Real-world cases are not limited to that. > And what happens if you add > > B baz(char); > > to the above -- will it show 2 candidates or just one? Dunno. As David Engster explained, CEDET does the simplest thing (take one of the overloads and ignore the rest.) > I don't know why you are saying this. E.g., a "parser armed with some > ad-hoc heuristics" that we have in ebrowse seems to be able to catch a > significant subset of C++, certainly of C++ that existed when ebrowse > was written. Why couldn't we base this feature on an extended ebrowse > engine? Today's C++ common usage would look totally alien to a programmer coming from the year 2000. Ebrowse is for "C with classes" more than C++. AFAIK Ebrowse will choke at the first occurrence of a template, for example. Also its intended usage is quite more modest than the functionality required for smart completion, not to mention refactoring. > ECB also supports mart completion. For C++? Not really. It only works as long as your code is simple enough, but that's because it implements the simplest cases. I tried it several times on my code base and the time saved on the cases where it worked was not enough to compensate for the cases where it didn't, leaving aside the frustration of the continous wtf!! moments. > 4 years ago people complained that > it's slow, but machines became faster since then, so perhaps things > are not so bad now, and we could use Semantic for this purpose. If Semantic is slow supporting the easiest, simplest parts of the C++ source code analysis... think about how slow would it be if it implemented the missing parts, those that make C++ compilers really slow compared to their C counterparts. >> Clang provides code completion as a sample of its capabilities. >> Clang/LLVM in fact is a set of libraries for dealing with C/C++ code. >> You can use those libraries for code completion and for any other >> feature that requires accessing/processing information contained on >> source code: extracting declarations, sanitizing, instrumenting, >> optimizing, generating object code... > > Are there any Emacs packages that support those features? Dunno. But the point is that now that a tool exists for doing the heavy lifting, creating an Emacs package for exploiting C++ semantic information is feasible. >> One was already mentioned by Stephen Leake: refactoring. > > 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. >> Actually, >> anything that requires semantic knowledge of the source code you are >> working on. You could ask for a listing of places dependent of word >> size, for instance, or highlight the places where certain idiom is used. > > Doesn't ECB already support such features? I don't think so. It can't do that since its understanding of C++ is quite limited. >> 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? ;-) > 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. >> >> Why reinvent the wheel? >> > >> > Because we cannot get the one that's already invented? >> >> "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 :-)