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: clang/emacs/ecb/semantic Date: Mon, 03 Dec 2012 20:50:49 +0200 Message-ID: <8338znrmuu.fsf@gnu.org> References: <20940A983D814C6192ABFF2B7A269A88@gmail.com> <87wqx42nag.fsf@yandex.ru> <87ehjcrw70.fsf@engster.org> <87hao816w4.fsf@wanadoo.es> <87hao7ioos.fsf@kuiper.lan.informatimago.com> <87zk1yhib2.fsf@kuiper.lan.informatimago.com> <50BAE369.2030503@dancol.org> <50BC0383.30208@dancol.org> <83ehj7rrko.fsf@gnu.org> <874nk3njay.fsf@gnu.org> <838v9frpcq.fsf@gnu.org> <50BCEBFB.1090004@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1354560715 19948 80.91.229.3 (3 Dec 2012 18:51:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Dec 2012 18:51:55 +0000 (UTC) Cc: pjb@informatimago.com, cyd@gnu.org, rms@gnu.org, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 03 19:52:07 2012 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 1Tfb7d-0008Bb-8u for ged-emacs-devel@m.gmane.org; Mon, 03 Dec 2012 19:52:05 +0100 Original-Received: from localhost ([::1]:54007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfb7R-0007Wb-Id for ged-emacs-devel@m.gmane.org; Mon, 03 Dec 2012 13:51:53 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfb7P-0007Vi-Ah for emacs-devel@gnu.org; Mon, 03 Dec 2012 13:51:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tfb7L-0005Qq-01 for emacs-devel@gnu.org; Mon, 03 Dec 2012 13:51:51 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:37952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfb7J-0005Ph-5X; Mon, 03 Dec 2012 13:51:45 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MEG00I00X0PXH00@a-mtaout20.012.net.il>; Mon, 03 Dec 2012 20:50:58 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEG00I9FXOTWH20@a-mtaout20.012.net.il>; Mon, 03 Dec 2012 20:50:54 +0200 (IST) In-reply-to: <50BCEBFB.1090004@dancol.org> 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:155201 Archived-At: > Date: Mon, 03 Dec 2012 10:14:19 -0800 > From: Daniel Colascione > CC: Chong Yidong , pjb@informatimago.com, rms@gnu.org, > emacs-devel@gnu.org > > There was no GPLed text editor supporting bidirectional editing > because the work hadn't been done. That's not what really happened. There were at least 2 previous attempts, 10 years ago, to provide such an Emacs. They were rejected (for technical reasons, not ideological ones, but that's not important for the point I'm making). Someone could claim that by rejecting working solutions, Emacs delayed its bidi support by 10 years, and drove potential users to other, perhaps non-free, editors. The point is that the mere fact that a certain important requirements is not fulfilled might well have very good reasons. It is not enough to say "this niche is still empty" to prove that the decision to reject an existing solution was wrong. > Reducing functionality can *never* serve the cause of software > freedom. Free programs should be as technically strong as possible, > even if that means they can talk to non-free programs. It's up to > developers to produce free software so good that users choose to use > free programs together, and crippling free software so that it can't > interoperate with *anything*, be it free or non-free, is a "see no > evil" approach that's not only a strategic blunder, but an affront to > users. That's the same exaggerations and non-practical absolute terms again, sorry. I'm not convinced.