From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Meanness Date: Sat, 26 Jul 2008 10:49:05 -0700 Message-ID: <488B6391.2040500@emf.net> References: <20080726081019.GB1419@muc.de> <853alw3aq8.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1217091664 7178 80.91.229.12 (26 Jul 2008 17:01:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jul 2008 17:01:04 +0000 (UTC) Cc: Juanma Barranquero , Eli Zaretskii , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 26 19:01:52 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 1KMn9Q-0004zj-Gz for ged-emacs-devel@m.gmane.org; Sat, 26 Jul 2008 19:01:48 +0200 Original-Received: from localhost ([127.0.0.1]:38619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KMn8W-0006Xe-U3 for ged-emacs-devel@m.gmane.org; Sat, 26 Jul 2008 13:00:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KMn7n-0005q4-O2 for emacs-devel@gnu.org; Sat, 26 Jul 2008 13:00:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KMn7l-0005mt-CN for emacs-devel@gnu.org; Sat, 26 Jul 2008 13:00:07 -0400 Original-Received: from [199.232.76.173] (port=43197 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KMn7l-0005me-4v for emacs-devel@gnu.org; Sat, 26 Jul 2008 13:00:05 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:48201) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KMn7Z-0005Gc-7A; Sat, 26 Jul 2008 12:59:53 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.114.9] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 35683937; Sat, 26 Jul 2008 09:59:49 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <853alw3aq8.fsf@lola.goethe.zz> X-detected-kernel: by monty-python.gnu.org: 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:101545 Archived-At: David Kastrup wrote: > Improving "Emacs on Windows" is not > the same as improving Emacs because Emacs is targeted as a component of > the GNU system. Supporting Emacs on Windows is at best orthogonal to > that goal. > I dunno about that (about "at best orthogonal to that goal"). Emacs is supposed to be a *component*, I agree. As a component, one requirement is that it have excellent "fit" (aka "coupling") with other parts of a GNU system. Making Emacs work really well on today's GNU/Linux systems is probably the best way to force improvements to its coupling. However: As a *component*, especially one of such central, low-level importance, Emacs should also have excellent "orthogonality and self-containment" (aka "cohesion"). It should fit well with a larger GNU system but it should, internally, be flexible, self-contained, based on good abstractions, etc. It should fit GNU but it shouldn't be overly "intertwingled" with GNU. The best way to force improvements to cohesion is by "porting" and using the component in comparable but substantially different environments. Windows is such. There aren't a lot of others to pick from. That so many, including many who certainly do support free software can benefit from Emacs on Windows is just icing on the cake. Two simple examples: fonts and colors. If the abstractions at the Emacs lisp level for fonts and colors are agnostic with respect to GNU vs. Windows and are effective on both, *that improves the quality of the Emacs component on GNU systems* by shaking out any needless intertwingling with X11 abstractions. That, in turn, makes it easier in the future (if need or desire be) to try some other window system besides X11 on GNU. It's easier because programs like Emacs are already very clean *components*. Don't get me wrong. Maintaining the Windows port *poorly* can do at least as much harm as good -- turning Emacs into a tangle of new #ifdefs, turning Emacs lisp into a language that works differently on different platforms, leading to *two* build systems instead of one, etc. Doing it well, though, should improve emacs *on GNU* in ways that almost no other plausible activity can do. -t >