From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Wed, 26 Feb 2014 22:54:20 +0200 Message-ID: <83ob1ty4qr.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1393448071 4170 80.91.229.3 (26 Feb 2014 20:54:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2014 20:54:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 26 21:54:39 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 1WIlV1-0004Vu-8K for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 21:54:39 +0100 Original-Received: from localhost ([::1]:43157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIlV0-0004P0-Qh for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 15:54:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIlUs-0004No-Gg for emacs-devel@gnu.org; Wed, 26 Feb 2014 15:54:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIlUn-0000sS-5t for emacs-devel@gnu.org; Wed, 26 Feb 2014 15:54:30 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:43800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIlUm-0000sI-O7 for emacs-devel@gnu.org; Wed, 26 Feb 2014 15:54:25 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N1M00D00ET8QM00@mtaout27.012.net.il> for emacs-devel@gnu.org; Wed, 26 Feb 2014 22:52:26 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1M00EWCFBEUG00@mtaout27.012.net.il>; Wed, 26 Feb 2014 22:52:26 +0200 (IST) In-reply-to: <87ppm9d3y4.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:169893 Archived-At: > From: =D3scar Fuentes > Date: Wed, 26 Feb 2014 21:17:07 +0100 >=20 > Eli Zaretskii writes: >=20 > > Would it be so bad if it showed 2 candidates instead of one? >=20 > IMO, yes. The "smart" part of "smart completion" is that only suita= ble > candidates are shown. Something else just causes confusion and > compile-edit cycles. Also, that example used a method for each clas= s. > Real-world cases are not limited to that. >=20 > > And what happens if you add > > > > B baz(char); > > > > to the above -- will it show 2 candidates or just one? >=20 > Dunno. I suggest to try (I did). Maybe then you will be less radical in you= r judgment of having N+1 candidates when only N are strictly needed. > 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. > Today's C++ common usage would look totally alien to a programmer c= oming > 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 examp= le. > Also its intended usage is quite more modest than the functionality > required for smart completion, not to mention refactoring. There's a thing called "extensions", you know. The Emacs 23 display engine was abysmally inadequate for bidirectional scripts, and yet relatively minor changes extended it to be adequate. I say "minor" because the basic design of the display engine remains intact. So I don't quite understand why you decided (without trying) that non= e of the existing solutions can be extended to fit the bill. Are you seriously claiming that clang is the _only_ way to go? I hope not. > > ECB also supports mart completion. >=20 > For C++? Not really. How do you know? When did you last try? If not recently, perhaps it got better since then? Did you attempt to analyze what is missing an= d how hard would it be to add that? > > 4 years ago people complained that > > it's slow, but machines became faster since then, so perhaps thin= gs > > are not so bad now, and we could use Semantic for this purpose. >=20 > 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. Who said it was slow _today_? I found complaints from 2009, are you really going to claim they are still relevant, without checking out? > >> 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 othe= r > >> 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? >=20 > Dunno. But the point is that now that a tool exists for doing the h= eavy > lifting, creating an Emacs package for exploiting C++ semantic > information is feasible. >=20 > >> 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? >=20 > No. My knowledge is far from exhaustive, though. Then perhaps the assertiveness of your opinions should be on par with how much you know. > >> Actually, > >> anything that requires semantic knowledge of the source code you= are > >> working on. You could ask for a listing of places dependent of w= ord > >> size, for instance, or highlight the places where certain idiom = is used. > > > > Doesn't ECB already support such features? >=20 > I don't think so. It can't do that since its understanding of C++ i= s > quite limited. Statistics doesn't understand anything about the underlying phenomena= , and yet it is able to produce very useful results. IOW, we don't nee= d 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. > >> IIRC I already told you this a few weeks ago, but I'll repeat: a= C++ > >> front-end (even without code generation capabilities) requires a= n > >> 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, >=20 > Since 100% is perfect, why should I wish more? ;-) I don't know, you tell me. > > which is certainly a requirement > > for a compiler. But we don't need such strict requirements for t= he > > features we are discussing, I think. >=20 > A defective refactoring tool can easily cause more work than it sav= es. > It can introduce subtle bugs, too. "Defective" is a far cry from "non-strict requirements", don't you think? > >> >> Why reinvent the wheel? > >> > > >> > Because we cannot get the one that's already invented? > >>=20 > >> "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 in= to > > something that could hopefully lead to a working implementation. >=20 > I'm not interested on politics either. I just wanted to be accurate= :-) To what end?