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 18:43:33 +0200 Message-ID: <834n3lzux6.fsf@gnu.org> References: <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <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> 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 1393433030 12787 80.91.229.3 (26 Feb 2014 16:43:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2014 16:43:50 +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 17:43:58 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 1WIhaL-0006xl-4d for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 17:43:53 +0100 Original-Received: from localhost ([::1]:41659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIhaK-000373-E9 for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 11:43:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIhaC-00036t-SO for emacs-devel@gnu.org; Wed, 26 Feb 2014 11:43:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIha6-0003w0-N1 for emacs-devel@gnu.org; Wed, 26 Feb 2014 11:43:44 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:39211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIha6-0003vn-E4 for emacs-devel@gnu.org; Wed, 26 Feb 2014 11:43:38 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N1M009003OQM700@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Wed, 26 Feb 2014 18:43:37 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1M009EW3SOD050@a-mtaout20.012.net.il>; Wed, 26 Feb 2014 18:43:37 +0200 (IST) In-reply-to: <871tyqes5q.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:169886 Archived-At: > From: =D3scar Fuentes > Date: Tue, 25 Feb 2014 23:36:33 +0100 >=20 > struct A { > int foo(); > }; >=20 > struct B { > int bar(); > }; >=20 > A baz(int); > B baz(A); >=20 > int quux(char c) { > return baz(c). ??????????? > } >=20 > For knowing the correct completion candidates at the point indicate= d by > the question marks you need to know which `baz' overload to choose, > which in turn requires to know that `c' is a `char' and then knowin= g > that a `char' is acceptable by the `baz' overload that takes an `in= t'. > Therefore you know that the correct `baz' overload returns an `A' a= nd > therefore the list of completion candidates is `foo'. Would it be so bad if it showed 2 candidates instead of one? And what happens if you add B baz(char); to the above -- will it show 2 candidates or just one? > Even this very simple case requires knowing the semantics of C++. E= ven > if this looks approachable by a parser armed with some ad-hoc > heuristics, those will surely fail by just adding/modifying a coupl= e of > lines on the test case above, unless those heuristics implement sem= antic > analysis under cover. I don't know why you are saying this. E.g., a "parser armed with som= e 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 ebrows= e engine? ECB also supports mart completion. 4 years ago people complained tha= t 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. > >> Furthermore, people here are talking too much about completion > > > > Well, that's the only thing that clang has that prompted this thr= ead, > > right? >=20 > Clang provides code completion as a sample of its capabilities. > Clang/LLVM in fact is a set of libraries for dealing with C/C++ cod= e. > 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? > 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? > Actually, > anything that requires semantic knowledge of the source code you ar= e > 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? > > We can always prototype in Lisp, then reimplement the slow parts = in C > > if needed. >=20 > 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 nee= ds > improvements as new standards are published. Only if you need to be 110% accurate, which is certainly a requiremen= t for a compiler. But we don't need such strict requirements for the features we are discussing, I 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 into something that could hopefully lead to a working implementation.