From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Wed, 07 Jan 2015 21:46:14 -0500 Message-ID: References: <83bnxuzyl4.fsf@gnu.org> <87fvn0senq.fsf@uwakimon.sk.tsukuba.ac.jp> <8761nusb90.fsf@uwakimon.sk.tsukuba.ac.jp> <87vbkovhh7.fsf@engster.org> <87387rvobr.fsf@engster.org> <83ppat84hk.fsf@gnu.org> <20150106143933.0090bc83@jabberwock.cb.piermont.com> <83r3v77ij6.fsf@gnu.org> <20150106154539.3d0752c4@jabberwock.cb.piermont.com> <87wq4ype3z.fsf@fencepost.gnu.org> Reply-To: rms@gnu.org NNTP-Posting-Host: plane.gmane.org Content-Type: text/plain; charset=Utf-8 X-Trace: ger.gmane.org 1420685260 12694 80.91.229.3 (8 Jan 2015 02:47:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Jan 2015 02:47:40 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, deng@randomsample.de, perry@piermont.com To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 08 03:47:35 2015 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 1Y9377-0004cn-MO for ged-emacs-devel@m.gmane.org; Thu, 08 Jan 2015 03:46:21 +0100 Original-Received: from localhost ([::1]:43789 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9376-0005Wp-TJ for ged-emacs-devel@m.gmane.org; Wed, 07 Jan 2015 21:46:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9372-0005WY-IG for emacs-devel@gnu.org; Wed, 07 Jan 2015 21:46:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9371-0000xc-Lb for emacs-devel@gnu.org; Wed, 07 Jan 2015 21:46:16 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9371-0000xY-JR for emacs-devel@gnu.org; Wed, 07 Jan 2015 21:46:15 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Y9370-0004eA-OM; Wed, 07 Jan 2015 21:46:14 -0500 In-reply-to: <87wq4ype3z.fsf@fencepost.gnu.org> (message from David Kastrup on Wed, 07 Jan 2015 20:47:28 +0100) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:181040 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > foo.x - bar.y > > > > it makes no difference for completion what that operator is. > In C++, I am afraid you are wrong. It depends on what types operator+ > and operator- may be defined for. If you define operator+ on a > half-group, you won't generally have operator- available. Could you explain how that is so? If + and - accept different types, how does that affect completion? Eli tried to explain > In an object-oriented language that supports operator overloading, the > + or - can do anything, and accept only specific data types under > certain constraints. For example, if foo.x is of a certain data type, > the candidates for the right-hand operand might be restricted to a > small subset of what a + or a - can generally support. If you > complete to a large list of candidates here disregarding the > constraints, you'd leave a lot of users unhappy. but he didn't give the substance, so I still don't follow. I have never used C++. > But the plugin interface then needs to be general and convenient enough > to get any aspect of it on-demand. And with regard to enabling > undesirable uses of it, I don't see that this buys us significant > savings over a non-Emacs specific AST dump. Are you thinking of this only in terms of the amount of work? I'm concerned with avoiding dangers. If you want to convince me generating the whole AST is safe, you have to understand my concern and take it seriously. You can't do this by brushing off the issue. That will only convince me that you haven't seen the issue. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call.