From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Taylan Ulrich Bayirli/Kammer Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Thu, 18 Sep 2014 16:12:49 +0200 Message-ID: <877g11uie6.fsf@taylan.uni.cx> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <878uliwajb.fsf@taylan.uni.cx> <87lhpitg6t.fsf@fencepost.gnu.org> <87wq92uhwh.fsf@taylan.uni.cx> <87wq91si9s.fsf@fencepost.gnu.org> <87oauduue2.fsf@taylan.uni.cx> <87a95xs0j8.fsf@fencepost.gnu.org> <87bnqdupyc.fsf@taylan.uni.cx> <8761glrv2f.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411049630 14290 80.91.229.3 (18 Sep 2014 14:13:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Sep 2014 14:13:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 18 16:13:43 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 1XUcSs-00018U-Jq for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 16:13:42 +0200 Original-Received: from localhost ([::1]:51440 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUcSs-0004Tq-5t for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 10:13:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUcSD-0003uJ-4e for emacs-devel@gnu.org; Thu, 18 Sep 2014 10:13:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUcSB-0006Jb-Kp for emacs-devel@gnu.org; Thu, 18 Sep 2014 10:13:01 -0400 Original-Received: from mail-la0-x232.google.com ([2a00:1450:4010:c03::232]:52359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUcSB-0006IQ-Cm; Thu, 18 Sep 2014 10:12:59 -0400 Original-Received: by mail-la0-f50.google.com with SMTP id ty20so1244035lab.9 for ; Thu, 18 Sep 2014 07:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=eQysjA9AvZ+SyL0Kp8aH24Stf3ft27b268Mz3rvBssk=; b=btTy/Xu2wqAMONI6rktE+meyIi67Ye7iN8FA+xSm+cQ2tMfZ6dTnddMsFh6EoxlDPf L5CbGyuQNh/rxT9JjaLFyLrfhQOwgIfwgQ18qMN3Z2ihF8ZKTZNj0jJ/h3J3MG+QNDiV etLoET6p9z3Zp2Bl3e4N7vAy9wzHESziKy5uGe5hOxjslqObq6ASNOFZ/9fTju/e9QZa LdxsxEKmQvw5Jeit1TetOu289P3cSmCQemt0VVXDwvH9DdN7KJpP6qPNffxJuvqN1QtX v21cgafzg5ua8bqZPX+bg4Hx0otFgsHDC8bRlPU5SR7K0xEDdGqpcnCMjJF1e/U+iWSf 15HA== X-Received: by 10.152.22.137 with SMTP id d9mr5167831laf.29.1411049573039; Thu, 18 Sep 2014 07:12:53 -0700 (PDT) Original-Received: from taylan.uni.cx (p200300514A48ABF10213E8FFFEED36FB.dip0.t-ipconnect.de. [2003:51:4a48:abf1:213:e8ff:feed:36fb]) by mx.google.com with ESMTPSA id s1sm2726397lag.26.2014.09.18.07.12.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Sep 2014 07:12:52 -0700 (PDT) In-Reply-To: <8761glrv2f.fsf@fencepost.gnu.org> (David Kastrup's message of "Thu, 18 Sep 2014 14:07:20 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::232 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:174499 Archived-At: David Kastrup writes: > At any rate, it has been mentioned previously in this discussion that > the Emacs developer list is not always considered a happy-go-lucky > environment. So if it is the habit of GUILE developers to take out > revenge on a project and its users for enmity with single developers, > that's also relevant for making crucial GNU software depend on GUILE. I don't see the Guile developers taking revenge on anyone --especially not LilyPond as a whole-- but rather flaying off your efforts to take revenge on them by passing on your anger. No need to be happy-go-lucky, just less insulting. You could probably continue taking part on guile-devel if you were more cooperative. > I think this interpretation of events is not making for a much better > outlook. Particularly because Emacs development is more often than > other GNU projects governed by unpopular political decisions. A habit > of retaliation and "see-where-this-will-get-you" in order to pressure > for a change in project lead is not likely going to work out well. It's ironic that you would talk about retaliation and "see-where-this-will-get-you" behavior, or am I misunderstanding? :-) It feels more like that's your attitude, despite there being no pressure from the Guile side. > I don't think that you are better off selling this situation as a > personal vendetta, and it is not like the GUILE 2 problem was not > already there when I started to get involved with LilyPond. Let's be honest here, it was obvious from your first mail on this thread that there's something personal going on. I knew absolutely nothing about your history on guile-devel (did not even recognize your name), yet guessed immediately that there was something fishy. >> Guile has authority over Guile-Scheme, but not over Elisp; it has to >> and will support Elisp as defined by Emacs as much as possible. >> That's pretty obvious I'd say. > > "This is not possible" will be defined under the constraints of GUILE > remaining Scheme according to GUILE's vision of interpretating the > Scheme standard and its further evolution. Reminder that Guile-Emacs, in its current alpha state, already runs ERC, Gnus, rcirc, Dired, term, comint, TRAMP, c-mode, etc. There will definitely not be much that is impossible. > The question now is not where GUILE will take Elisp but rather whether > its interpretation of Elisp can get close enough to make a switch > feasible in the first place. See above. Also, compilation, not interpretation. :} Taylan