From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Changes 2009-07-15/16 in branch? Date: Fri, 24 Jul 2009 13:12:45 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <4A692E0A.9060108@gnu.org> 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 1248408789 25177 80.91.229.12 (24 Jul 2009 04:13:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2009 04:13:09 +0000 (UTC) Cc: Adrian Robert , Stefan Monnier , Emacs-Devel devel To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 24 06:13:02 2009 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 1MUC9U-0005VW-Qp for ged-emacs-devel@m.gmane.org; Fri, 24 Jul 2009 06:13:01 +0200 Original-Received: from localhost ([127.0.0.1]:56611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUC9T-00026Z-Vu for ged-emacs-devel@m.gmane.org; Fri, 24 Jul 2009 00:13:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MUC9P-00026U-Ui for emacs-devel@gnu.org; Fri, 24 Jul 2009 00:12:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MUC9K-00026I-AU for emacs-devel@gnu.org; Fri, 24 Jul 2009 00:12:54 -0400 Original-Received: from [199.232.76.173] (port=55299 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUC9K-00026F-6z for emacs-devel@gnu.org; Fri, 24 Jul 2009 00:12:50 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:49312) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MUC9H-0005NE-83; Fri, 24 Jul 2009 00:12:47 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 792782C44; Fri, 24 Jul 2009 13:12:45 +0900 (JST) In-Reply-To: <4A692E0A.9060108@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by monty-python.gnu.org: NetBSD 3.0 (DF) 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:113085 Archived-At: >>>>> On Fri, 24 Jul 2009 11:44:10 +0800, Jason Rumney said: > YAMAMOTO Mitsuharu wrote: >> I don't agree in this respect. Reverting the changes in the branch >> will result in breaking compatibility TWICE: >> >> * On 23.1, between the NS port and the other platforms. >> * On the NS port, between 23.1 and 23.2. >> >> We should provide some care compensating for these breakages. >> >> Note that I'm trying to find a constructive solution as we agree in >> many other respects. >> > One solution is for 23.2 to provide an ns-compat.el library containing > wrapper functions mapping the incompatible features > to their platform-independent replacements and emitting warnings to > inform the user that they should change to use the platform-independent > equivalents. Then in 23.3 or 24.1 we could remove this library from > Emacs and require users to get it from elsewhere if they still want to > use the incompatible features. Perhaps this can be applied to some of the features I removed. Let's take a more closer look. There might be a possibility of different solutions for different changes. What I removed was: 1. Code for stippling. This is wrongly implemented as tiling, which has been controversial whether or not to be included in the other platforms, IIUC. 2. Code for interpreting incompatible color formats: RGBrrggbb, ARGBaarrggbb, HSVhhssvv, AHSVaahhssvv, and CMYKccmmyykk. Besides the format itself, support for the alpha-component in color is not found in the other platforms but not inherently NS-specific. 3. Lisp primitive ns-set-alpha (nsfns.m), which sets the alpha component of the given color to the specified value. As in the argument for the alpha-component above, this is not inherently NS-specific. 4. Lisp function ns-set-background-alpha (ns-win.el), which sets alpha-component of frame background color. It is different from the frame parameter `alpha' as Adrian explained. Again, this is not inherently NS-specific. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp