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, 21 Feb 2014 08:04:18 +0100 Message-ID: <87sirdhrpp.fsf@fencepost.gnu.org> References: <834n41db0d.fsf@gnu.org> <52FE2985.4070703@yandex.ru> <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <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> <8761o9jq8n.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392966350 27799 80.91.229.3 (21 Feb 2014 07:05:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Feb 2014 07:05:50 +0000 (UTC) Cc: Dmitry Gutov , Emacs developers To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 21 08:05:57 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 1WGkBH-0002Xh-W1 for ged-emacs-devel@m.gmane.org; Fri, 21 Feb 2014 08:05:56 +0100 Original-Received: from localhost ([::1]:42515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGkBH-0000SO-H8 for ged-emacs-devel@m.gmane.org; Fri, 21 Feb 2014 02:05:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGkBE-0000S7-J4 for emacs-devel@gnu.org; Fri, 21 Feb 2014 02:05:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGkBC-0004m4-Ng for emacs-devel@gnu.org; Fri, 21 Feb 2014 02:05:52 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGkBC-0004m0-Jv for emacs-devel@gnu.org; Fri, 21 Feb 2014 02:05:50 -0500 Original-Received: from localhost ([127.0.0.1]:60376 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGkBC-0002TQ-4B; Fri, 21 Feb 2014 02:05:50 -0500 Original-Received: by lola (Postfix, from userid 1000) id D11E4E04EA; Fri, 21 Feb 2014 08:04:18 +0100 (CET) In-Reply-To: (John Yates's message of "Thu, 20 Feb 2014 22:45:29 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) 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:169800 Archived-At: John Yates writes: >> Even when that has been done, one still has to do an actual >> implementation and _then_ have to see whether under the constraints >> of the current implementation the hoped-for advantages are actually >> as envisioned, and the accepted drawbacks don't turn out larger than >> expected. And there is not much of an option to turn back the clock, >> either. > > Do I understand you correctly here? Did you just conceded my original > point, namely that while RMS does not want us to dissipate the pent up > demand that could drive gcc into the tool space, that transformation > most likely will never happen? It feels like talking to a wall with you guys. I am not even mentioning Richard here. I am explaining the situation one needs to take into account. If you refuse thinking about the situation, you won't ever reach an agreement. > IOW emacs-based C++ developers are denied valuable tools that are > becoming ever more common in other development environments based on a > chimera. Stomping your feet and pouting is all very nice but I suggest that you bother with actually putting yourself in the shoes of Richard with regard to the conflicting goals he is trying to manage. Without bothering to see his side, you will have a hard time changing his views and what results they lead to. In particular, since you're one of those who is going to oversee the technical execution. If you don't appear to understand what this is even about, whether or not you share the exact priorities, you'll not be able to stay on a path that is going to be quite trickier than a plain "we won't go there". -- David Kastrup