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: Sat, 25 Jul 2009 10:15:34 +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 1248484575 11045 80.91.229.12 (25 Jul 2009 01:16:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jul 2009 01:16:15 +0000 (UTC) Cc: Emacs-Devel devel To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 25 03:16:08 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 1MUVrq-000893-TQ for ged-emacs-devel@m.gmane.org; Sat, 25 Jul 2009 03:16:07 +0200 Original-Received: from localhost ([127.0.0.1]:53962 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUVrq-0000QH-6A for ged-emacs-devel@m.gmane.org; Fri, 24 Jul 2009 21:16:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MUVrW-0008SB-7X for emacs-devel@gnu.org; Fri, 24 Jul 2009 21:15:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MUVrR-0008Jy-Gm for emacs-devel@gnu.org; Fri, 24 Jul 2009 21:15:45 -0400 Original-Received: from [199.232.76.173] (port=46529 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUVrQ-0008Jl-Vj for emacs-devel@gnu.org; Fri, 24 Jul 2009 21:15:41 -0400 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2]:64653 helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MUVrQ-0006aR-0T for emacs-devel@gnu.org; Fri, 24 Jul 2009 21:15:40 -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 782EE2C40; Sat, 25 Jul 2009 10:15:34 +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:113115 Archived-At: >>>>> On Fri, 24 Jul 2009 10:34:55 -0400, Adrian Robert said: > On Jul 23, 2009, at 8:46 AM, YAMAMOTO Mitsuharu wrote: >> 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!). > There are others working on the port, but speaking for myself, my time > has been limited and I've prioritized fixing bugs (as I've mentioned > before). I've advocated for and assisted others with > standardization / cleanup efforts. They would hesitate to remove the code even if it breaks compatibility unless you explicitly ask it. >> 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. > Then let's mark it such, as there are many more features of this sort > that should be removed by your criteria (some of which were > unfortunately adopted by the Carbon port following Emacs.app in the > Sourceforge days, but were never subjected to the same scrutiny): > - modifier key customization (standard methods exist) > - services integration (no counterpart on other platforms) > - applescript integration (use DBUS instead) > - font panel (unneeded, incompatible) > - nonstandard antialiasing controls (standard methods exist) > - nonstandard way of hiding/showing toolbar (unneeded, incompatible) > - open/save panels (unneeded, incompatible) > - about panel (unneeded) Whether or not to mark experimental/hackers-only is up to the maintainers, and I actually asked them about the status of the port before removing the code. http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00630.html And actually I considered whether I can remove some of the incompatible features you listed above, say open/save panel. But it is too drastic to do so without some replacement code. Addition of such code is "too late" and regression-prone, so I restricted myself to the features that just removal is sufficient. >>> 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. > I gathered that you understood it better than I so I was wondering if > there was some reason to just remove code when fixing it would have > been as easy. As I said above, I avoided adding replacement code. >>> 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) > "Inherently specific" is an ambiguous call, and I don't think it's a > reasonable litmus test. But if the Cocoa APIs provide alpha > capabilities beyond what is available on X11 and W32, it is inherent > in some sense. The right thing would be to fix the frame-parameter > implementation (at least on NS), but failing that the other option > should be left in for users. I think fundamental features such as alpha-component needs some consensus among platforms about its specification. Of course, platform-specific proof-of-concept code is sometimes useful to call for discussion, but it doesn't fit with the official release version as it is. >> 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. > It seems there are several problems listed in the email you cite that > either do not impact or actually hurt users; why not work on these (on > the trunk), or on fixing bugs? As I already said, I suspect the port has fundamental design flaw (not 100% sure, so you can possibly refute it). And design and policy are too different from mine. What I would do with Cocoa can be found in my Carbon+AppKit port. > As far as the superseded / platform independent argument, as I've said > before, many features first appeared on X11 or GTK without > counterparts on other platforms. This continues to happen now. It's > a double-standard to police the NS port so stringently without > considering implementing the counterparts. I thought RMS is strongly against adding features to proprietary platforms first. Of course, it is not applied to inherently platform-specific features (such as Apple Event handling). Maybe if you make the GNUstep port much more stable and usable enough as "first-class" port, then you can add some features first to the platform, but I'm not sure. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp