From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Fri, 28 Feb 2014 10:13:58 +0100 Organization: Organization?!? Message-ID: <871tyn4n1l.fsf@fencepost.gnu.org> References: <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> <83eh2oxpnw.fsf@gnu.org> <877g8gcl52.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1393578869 15628 80.91.229.3 (28 Feb 2014 09:14:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Feb 2014 09:14:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 28 10:14:34 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 1WJJWZ-00077a-RQ for ged-emacs-devel@m.gmane.org; Fri, 28 Feb 2014 10:14:32 +0100 Original-Received: from localhost ([::1]:49895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJJWZ-0004pF-DK for ged-emacs-devel@m.gmane.org; Fri, 28 Feb 2014 04:14:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJJWQ-0004mF-PV for emacs-devel@gnu.org; Fri, 28 Feb 2014 04:14:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJJWL-0007hH-GD for emacs-devel@gnu.org; Fri, 28 Feb 2014 04:14:22 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:50921) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJJWL-0007hD-9E for emacs-devel@gnu.org; Fri, 28 Feb 2014 04:14:17 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WJJWJ-000641-7n for emacs-devel@gnu.org; Fri, 28 Feb 2014 10:14:15 +0100 Original-Received: from x2f43b62.dyn.telefonica.de ([2.244.59.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Feb 2014 10:14:15 +0100 Original-Received: from dak by x2f43b62.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Feb 2014 10:14:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 52 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f43b62.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:HHzkYUN40OGNC6njuZ2h0UR6Tyo= 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:169925 Archived-At: Óscar Fuentes writes: > Eli Zaretskii writes: > >> What happened to the other one? It is still in the source. > > Smart completion is all about showing the appropriate completions for > the context where the point is. Once you know the number and type of > arguments, if you have zero or more than one acceptable overloads, the > code is malformed. Barred that, there is one and only one correct > overload, which is the one the compiler will use. A correct smart code > completion system will show precisely that overload. > > That's what a C++ programmer expects, and then I'm perplexed when I read > this: > > [snip] > >>> Eli, are you a C++ programmer? Do you code in C++ on a regular basis? >> >> Yes! > > It is obvious then that we have here a complete miscomunication, so I'll > stop the discussion here. The miscommunication appears to be that you apparently are convinced that coding C++ on a regular basis is impossible without using crutches. It is my opinion that writing a code style that can neither be written nor understood without reverting to computer help is a bad idea. Writing a code style that can neither be written nor understood without letting a full-blown compiler take a look at it is an even worse idea. If you consider that a _regular_ part of your coding practices, you are writing code that can only be maintained by throwing it away and rewriting from scratch. This step will become necessary in particular whenever the C++ standards change in some manner. That may be putting it overbluntly, but I am absolutely unsurprised that someone coding C++ on a regular basis does _not_ find himself on the edge of ambiguities so often that he requires constant handholding by his tools in order to produce working code. When one declaration changes the meaning and syntax of a program all over one file (and yes, this sort of thing _can_ happen with C++), getting things right might require a full-file parse. When presented with a preexisting C++ file, being able to get the actual meaning out by the use of exhaustive tools is nice. When _writing_ a C++ program, it's preferable to stay away from those edges and thus get along with more simplistic tools. Or even none at all. -- David Kastrup