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: Thu, 23 Jul 2009 21:46:48 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: 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 1248353237 24544 80.91.229.12 (23 Jul 2009 12:47:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jul 2009 12:47:17 +0000 (UTC) Cc: Emacs-Devel devel To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 23 14:47:10 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 1MTxhT-0007iH-NL for ged-emacs-devel@m.gmane.org; Thu, 23 Jul 2009 14:47:08 +0200 Original-Received: from localhost ([127.0.0.1]:56835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTxhS-0006ur-P0 for ged-emacs-devel@m.gmane.org; Thu, 23 Jul 2009 08:47:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTxhL-0006t4-FO for emacs-devel@gnu.org; Thu, 23 Jul 2009 08:46:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTxhH-0006oX-Qa for emacs-devel@gnu.org; Thu, 23 Jul 2009 08:46:59 -0400 Original-Received: from [199.232.76.173] (port=46527 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTxhH-0006oE-Ku for emacs-devel@gnu.org; Thu, 23 Jul 2009 08:46:55 -0400 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2]:50017 helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTxhG-0005Ou-Sa for emacs-devel@gnu.org; Thu, 23 Jul 2009 08:46:55 -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 1ADF12C40; Thu, 23 Jul 2009 21:46:49 +0900 (JST) In-Reply-To: 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:113053 Archived-At: >>>>> On Thu, 23 Jul 2009 07:22:55 -0400, Adrian Robert said: > Hello Yamamoto-san, Did you mean to check the changes below into the > branch? I *think* these are pretty safe, but it seems a bit close > to release for such feature changes, even in the name of > standardization. My vote would be to do these on trunk only for > now. Chong Yidong already made a query to me via a private mail. Below is my reply: It's essential to make these changes in the release branch so users may not use the incompatible formats by accident and introduce compatibility problems when they are removed in some future version. Upcoming version is the first one for the NS port. Effectiveness is much lowered if such changes are deferred to the later versions. I've warned about such incompatibility issues that I think indispensable for the first official release version, but the author has not tried to address them (not just for this one!). Even if by any chance there's overlooked code as you say, it's only in the NS-specific part and relatively minor compared with total unstableness of the port itself. Removing incompatible features at this timing is much more important unless the port is marked experimental/hackers-only. Anyway, let's wait at least a few days before making any changes in this respect. > Also: > ns_get_color(): Shouldn't the description comment for ns_get_color() > be updated further? It looks like something was just chopped off, > leaving the rest making little sense. What is the bug or problem > this change fixes? > ns_color_to_lisp(): The function could be simplified now that you > have eliminated a special case. I know the changes are not optimal. But I wanted to keep them quite straightforward so as to avoid regression. > nsfont_draw(): Would setting the foreground instead of the > background color to the bitmap constitute a corrected > implementation? I don't know if I understand your intention correctly from the above sentence. But if you believe you understand stippling correctly this time, maybe you can make the change into the trunk. > ns-set-background-alpha: The implementation you just removed was > superior to that for (set-frame-parameter nil 'alpha ##): it does > not alter the alpha of the titlebar, scrollbars, modeline, or text. > This makes it usable, instead of a curiosity. It also provides > access via an interactive function. The correct fix would be to > improve the (set- frame-parameter) version, not remove this while no > alternative exists for users. I knew their difference. I removed it because it belongs to "NS-only implementation for features that are not inherently specific to NS." (http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html) I think it's really bad for the "first-class" port to have such features because they may be superseded in a platform-independent way by some future versions and that introduces unnecessary incompatibilities. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp