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: Meanness Date: Sat, 26 Jul 2008 20:36:03 +0300 Message-ID: References: <20080726081019.GB1419@muc.de> <853alw3aq8.fsf@lola.goethe.zz> <488B6391.2040500@emf.net> <85abg41rz8.fsf@lola.goethe.zz> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1217093789 12891 80.91.229.12 (26 Jul 2008 17:36:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jul 2008 17:36:29 +0000 (UTC) Cc: lekktu@gmail.com, lord@emf.net, 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:37:18 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 1KMnhh-0007ZY-N9 for ged-emacs-devel@m.gmane.org; Sat, 26 Jul 2008 19:37:14 +0200 Original-Received: from localhost ([127.0.0.1]:50205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KMngn-0007ES-MY for ged-emacs-devel@m.gmane.org; Sat, 26 Jul 2008 13:36:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KMngh-0007Cy-2I for emacs-devel@gnu.org; Sat, 26 Jul 2008 13:36:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KMngg-0007C4-8L for emacs-devel@gnu.org; Sat, 26 Jul 2008 13:36:10 -0400 Original-Received: from [199.232.76.173] (port=33669 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KMngg-0007Bz-4o for emacs-devel@gnu.org; Sat, 26 Jul 2008 13:36:10 -0400 Original-Received: from mtaout5.012.net.il ([84.95.2.13]:25548) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KMngb-0002XT-0r; Sat, 26 Jul 2008 13:36:05 -0400 Original-Received: from HOME-C4E4A596F7 ([77.127.123.9]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K4M000ULJK7WCI0@i_mtaout5.012.net.il>; Sat, 26 Jul 2008 20:36:08 +0300 (IDT) In-reply-to: <85abg41rz8.fsf@lola.goethe.zz> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 9.1 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:101549 Archived-At: > From: David Kastrup > Cc: Juanma Barranquero , Eli Zaretskii , emacs-devel@gnu.org > Date: Sat, 26 Jul 2008 19:21:31 +0200 > > > The best way to force improvements to cohesion is by "porting" and > > using the component in comparable but substantially different > > environments. Windows is such. > > No. Windows is not comparable. Various Unix variants are. There is > nothing to be gained for Emacs on GNU/Linux by having to support file > systems which use backslashes instead of slashes and have drive letters. Wrong. The gain is to have abstractions like IS_DIRECTORY_SEP and IS_ABSOLUTE_FILE_NAME, instead of testing for literal characters. The gain is to realize that file names are not simple strings and cannot be compared for equality with strcmp and its ilk. Such abstractions will serve us well when we get to supporting Unicode file names where normalization prevents simple string comparison. > Such things require creating artificial splicings of code and > pseudo-abstractions and APIs which make code less straightforward to > read and write. Yeah, and C++ abstractions make code less straightforward to read and write that C or assembly. Get real! > > 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. > > Uh no, it doesn't. Gdk (and Gtk) provide efficient color map and image > handling. Emacs doesn't. It is quite worse, and that's exactly because > of being reduced to lowest denominator handling and corresponding > interfaces. Wrong again: Emacs has text terminal color support that was lifted almost verbatim from the code written for the DOS port. The DOS code was written by implementing the abstract interface of Xlib. > Gtk/Pango provides right-to-left typesetting and > internationalization. Emacs doesn't. Irrelevant: Emacs cannot use Pango because it doesn't fit well the Emacs display engine, which walks the buffer one character at a time. > > Doing it well, though, should improve emacs *on GNU* in ways that > > almost no other plausible activity can do. > > My experience with Windows-too projects runs quite contrary. That is your experience. Mine is different. > Can we please _stop_ this silliness? Stop responding, if you want this to stop.