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: Thu, 27 Feb 2014 22:32:19 +0200 Message-ID: <83eh2oxpnw.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> <83ob1ty4qr.fsf@gnu.org> <87ha7lcxki.fsf@wanadoo.es> <83ios0xwcv.fsf@gnu.org> <87bnxscr0x.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 1393533150 28227 80.91.229.3 (27 Feb 2014 20:32:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2014 20:32:30 +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 Thu Feb 27 21:32:38 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 1WJ7dG-0007qL-0H for ged-emacs-devel@m.gmane.org; Thu, 27 Feb 2014 21:32:38 +0100 Original-Received: from localhost ([::1]:47822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ7dF-00014v-JV for ged-emacs-devel@m.gmane.org; Thu, 27 Feb 2014 15:32:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ7d4-0000tw-WE for emacs-devel@gnu.org; Thu, 27 Feb 2014 15:32:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJ7cz-0002eK-Kf for emacs-devel@gnu.org; Thu, 27 Feb 2014 15:32:26 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:55470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ7cy-0002do-PF for emacs-devel@gnu.org; Thu, 27 Feb 2014 15:32:21 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N1O003008NZWE00@mtaout28.012.net.il> for emacs-devel@gnu.org; Thu, 27 Feb 2014 22:32:42 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1O0001T92IFE50@mtaout28.012.net.il>; Thu, 27 Feb 2014 22:32:42 +0200 (IST) In-reply-to: <87bnxscr0x.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.184 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:169913 Archived-At: > From: =D3scar Fuentes > Date: Thu, 27 Feb 2014 20:08:30 +0100 >=20 > Eli Zaretskii writes: >=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 your > >> > judgment of having N+1 candidates when only N are strictly nee= ded. > >>=20 > >> 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 thi= nk it > > should have shown 2. >=20 > No. After adding your overload, there is just one candidate, namely= , > the one that exactly matches its argument type: char. What happened to the other one? It is still in the source. > > IMO, showing more candidates than strictly > > necessary is a lesser evil than showing less than necessary. >=20 > 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 dec= iding > 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 corr= ect > answer for the completion case, it would be a very broken C++ compi= ler > too. So? > I'm saying that a compiler infraestructure, with the correct interf= aces, > makes any other approach look as a hack, for the reason stated on m= y > previous paragraph. Well, I disagree, and I guess we will have to leave this at that. > Right now only Clang fits the bill No, it doesn't, not as long as there are no decent production-quality Emacs packages that use it. > Are you serious? Yes. > Eli, are you a C++ programmer? Do you code in C++ on a regular basi= s? Yes! > >> > Who said it was slow _today_? I found complaints from 2009, a= re you > >> > really going to claim they are still relevant, without checkin= g out? > >>=20 > >> Again, why do you assume that I didn't tried? > > > > How about publishing your data, then? >=20 > Which data? See above: that it is slow. > Sorry, but this looks more like handwaving than real argumentation. And you didn't? > 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? I hope because you want Emacs to become a better programming editor. > > This discussion _is_ about Emacs! It is not about parsing C++ fo= r any > > other purpose, or refactoring by other tools. Of course, knowled= ge of > > available tools for Emacs is extremely relevant. >=20 > If the tools were available, this discussion wouldn't arise. But since they aren't available, we have nothing to compare to, and s= o saying that CEDET or ECB are inadequate without that feature doesn't have any real basis. It's just propaganda. > >> > Statistics doesn't understand anything about the underlying ph= enomena, > >> > and yet it is able to produce very useful results. IOW, we do= n'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. > >>=20 > >> 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 lang= uage > > it supports, and yet it generally does a very good job in finding= the > > identifiers. >=20 > It is obvious that you don't understand the problem And you evidently don't understand the concept of analogy. > Surely they will not queue for inclusion, because they all were rej= ected > in advance. They don't exist, first and foremost. There's nothing to reject.