From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yavor Doganov Newsgroups: gmane.emacs.devel Subject: Re: Release update Date: Thu, 04 Dec 2008 19:08:29 +0200 Organization: The GNU Emacs Church (Bulgarian eparchy) Message-ID: <87tz9j6f76.GNU's_Not_Unix!%yavor@gnu.org> References: <87ej0rs3ey.fsf@cyd.mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1228410560 20763 80.91.229.12 (4 Dec 2008 17:09:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2008 17:09:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 04 18:10:23 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L8HiZ-0000sh-3U for ged-emacs-devel@m.gmane.org; Thu, 04 Dec 2008 18:10:23 +0100 Original-Received: from localhost ([127.0.0.1]:53278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8HhO-0001mR-Hq for ged-emacs-devel@m.gmane.org; Thu, 04 Dec 2008 12:09:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8Hgx-0001ae-RR for emacs-devel@gnu.org; Thu, 04 Dec 2008 12:08:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8Hgw-0001aE-P7 for emacs-devel@gnu.org; Thu, 04 Dec 2008 12:08:42 -0500 Original-Received: from [199.232.76.173] (port=40693 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8Hgw-0001aA-8F for emacs-devel@gnu.org; Thu, 04 Dec 2008 12:08:42 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:35127 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L8Hgv-0002oM-Ox for emacs-devel@gnu.org; Thu, 04 Dec 2008 12:08:42 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L8Hgr-0004yB-1k for emacs-devel@gnu.org; Thu, 04 Dec 2008 17:08:37 +0000 Original-Received: from 213.91.219.2 ([213.91.219.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Dec 2008 17:08:37 +0000 Original-Received: from yavor by 213.91.219.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Dec 2008 17:08:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 64 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 213.91.219.2 In-Reply-To: <87ej0rs3ey.fsf@cyd.mit.edu> Mail-Followup-To: emacs-devel@gnu.org, yavor@gnu.org User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) X-Jabber-ID: doganov@jabber.minus273.org X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106564 Archived-At: At Mon, 01 Dec 2008 21:43:01 -0500, Chong Yidong wrote: > > We are getting pretty close, and currently there are two main things > to do before starting the pretest: adding ruby-mode to the CVS > repository, and making rmail-mbox/pmail ready for use. I don't know what is the Emacs maintainers' opinion about the GNUstep port wrt release status/goals, but I'd like to mention that in its current form it is not usable as a replacement of GTK+/Lucid/nox. Maybe this is not a problem in general, as probably the main goal of the port is to make Emacs available for users of the Muck OS X system (as a replacement of the Carbon port). I don't see it this way, though, although I realize I'm in the minority. As a GNUstep user my goal is to use Emacs.app as a replacement of the Lucid build (or the GTK+ build with the GTK-Step GTK theme). This is not possible now, even with my extremely low Emacs usage requirements. Whether this is considered release-critical is up to the Emacs maintainers to decide, naturally. The trouble is that if GNUstep users don't find this flavor usable to run it by default, bugs will not be even discovered, let alone fixed. Of course, it is impossible to fix all bugs in time for the 23 release, but at least the most critical ones should be nailed. Here is a short summary of what I consider important for the GNUstep port (in my capacity as a humble user). I am still experimenting with some of the bugs to which Adrian sent useful comments. * #1333: Emacs.app does not load ~/.emacs The consequences of this are a real disaster. Emacs also doesn't inherit the environment, which in many cases makes usage of external processes a PITA. * #984: Emacs.app segfaults on startup with the cairo backend The cairo backend is still considered experimental in GNUstep Back, although probably 90% of the people are using it, because rendering is faster and much more beautiful than art. Not being able to use Emacs with cairo means "downgrading" to art, as it is not possible to define the backend on a per-app basis (and that's how it should be). This is a GNUstep problem, I think. * #620: Bootstrapping with the GNUstep port impossible Distro unfriendliness. This is not a problem for regular users, as released Emacs already contains byte-compiled files, and there is an easy workaround for bootstrapping anyway. However, nowadays the majority of the users prefer distro-provided packages. Among the distros who care about GNUstep and ship it, Emacs.app currently cannot be provided for Gentoo because of this, and for Debian (gNewSense actually) I am doing a horrible hack/workaround that no sane (Debian) maintainer would upload as an official package. As a result, I suspect that at the end this port will have even less testing. * Some GNU Coding Standards violations that I'm going to report soon (with patches, eventually). The problem, basically, is that the Emacs.app build system breaks certain user expectations that were in place since about forever. I hope that even intrusive patches for the GNUstep port will be accepted in the pretest period.