From: Adrian Robert <adrian.b.robert@gmail.com>
To: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Cc: Emacs-Devel devel <emacs-devel@gnu.org>
Subject: Re: Changes 2009-07-15/16 in branch?
Date: Fri, 24 Jul 2009 10:34:55 -0400 [thread overview]
Message-ID: <AADBBD39-E480-478D-B720-097867734346@gmail.com> (raw)
In-Reply-To: <wlmy6vzhvr.wl%mituharu@math.s.chiba-u.ac.jp>
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.
> 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)
All of these things belong in distributions, or in add-on packages
such as:
http://www.emacswiki.org/emacs/NSPlatformSupport
>> 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.
OK, then at least a cleaned-up version could have gone into the trunk.
>> 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.
>> 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 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 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.
next prev parent reply other threads:[~2009-07-24 14:34 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-23 11:22 Changes 2009-07-15/16 in branch? Adrian Robert
2009-07-23 12:46 ` YAMAMOTO Mitsuharu
2009-07-23 15:30 ` Stefan Monnier
2009-07-24 0:23 ` YAMAMOTO Mitsuharu
2009-07-24 1:09 ` Stefan Monnier
2009-07-24 1:27 ` YAMAMOTO Mitsuharu
2009-07-24 1:37 ` Stefan Monnier
2009-07-24 2:20 ` YAMAMOTO Mitsuharu
2009-07-24 3:17 ` Stefan Monnier
2009-07-24 3:35 ` YAMAMOTO Mitsuharu
2009-07-24 3:44 ` Jason Rumney
2009-07-24 4:12 ` YAMAMOTO Mitsuharu
2009-07-25 2:13 ` YAMAMOTO Mitsuharu
2009-07-26 2:22 ` Richard Stallman
2009-07-26 2:35 ` YAMAMOTO Mitsuharu
2009-07-26 3:31 ` Miles Bader
2009-07-26 3:45 ` YAMAMOTO Mitsuharu
2009-07-27 2:44 ` Richard Stallman
2009-07-27 3:20 ` YAMAMOTO Mitsuharu
2009-07-27 17:41 ` Richard Stallman
2009-07-27 18:41 ` Clifford Wulfman
2009-07-28 4:37 ` Richard Stallman
2009-07-28 13:18 ` Clifford Wulfman
2009-07-28 17:14 ` Richard Stallman
2009-07-28 18:39 ` Alfred M. Szmidt
2009-07-28 20:31 ` Ian Eure
2009-08-01 3:21 ` Richard Stallman
2009-08-01 4:10 ` Ian Eure
2009-08-01 6:28 ` Stephen J. Turnbull
2009-08-02 4:44 ` Richard Stallman
2009-07-28 22:05 ` James Cloos
2009-07-29 20:13 ` Richard Stallman
2009-07-29 22:05 ` YAMAMOTO Mitsuharu
2009-07-30 7:53 ` YAMAMOTO Mitsuharu
2009-07-30 14:01 ` Chong Yidong
2009-07-31 1:56 ` YAMAMOTO Mitsuharu
2009-07-27 20:14 ` David De La Harpe Golden
2009-07-28 6:10 ` YAMAMOTO Mitsuharu
[not found] ` <EFBC3E4E-8739-4B16-8797-D9CA8BC290CD@gmail.com>
2009-07-28 20:33 ` David De La Harpe Golden
2009-07-28 0:53 ` YAMAMOTO Mitsuharu
2009-07-28 17:14 ` Richard Stallman
2009-07-24 19:25 ` Stefan Monnier
2009-07-29 0:22 ` YAMAMOTO Mitsuharu
2009-07-29 1:12 ` Chong Yidong
2009-07-29 1:18 ` YAMAMOTO Mitsuharu
2009-07-29 4:48 ` YAMAMOTO Mitsuharu
2009-07-29 1:29 ` YAMAMOTO Mitsuharu
2009-07-24 14:34 ` Adrian Robert [this message]
2009-07-25 1:15 ` YAMAMOTO Mitsuharu
2009-07-25 4:55 ` Richard Stallman
2009-07-25 16:59 ` Adrian Robert
2009-07-27 2:43 ` Richard Stallman
2009-07-27 3:22 ` Adrian Robert
[not found] ` <E1MW1sm-0000lL-4K@fencepost.gnu.org>
2009-07-29 14:08 ` Harald Hanche-Olsen
2009-07-29 17:18 ` Stefan Monnier
2009-07-30 7:35 ` David Kastrup
2009-07-30 13:31 ` Harald Hanche-Olsen
2009-07-28 18:25 ` Harald Hanche-Olsen
2009-07-29 2:34 ` Stephen J. Turnbull
2009-07-29 2:41 ` Lennart Borgman
2009-07-29 2:56 ` Harald Hanche-Olsen
2009-07-29 3:33 ` Stephen J. Turnbull
2009-07-29 20:14 ` Richard Stallman
2009-07-29 20:26 ` Chad Brown
2009-07-30 15:35 ` Richard Stallman
2009-07-30 16:37 ` Harald Hanche-Olsen
2009-07-29 20:31 ` Harald Hanche-Olsen
2009-07-30 15:35 ` Richard Stallman
2009-07-30 16:22 ` Harald Hanche-Olsen
2009-08-01 3:21 ` Richard Stallman
2009-08-01 7:45 ` CHENG Gao
2009-08-01 9:36 ` CHENG Gao
2009-08-02 4:43 ` Richard Stallman
2009-08-02 7:06 ` CHENG Gao
2009-08-03 16:17 ` Richard Stallman
2009-08-03 20:03 ` CHENG Gao
2009-07-29 14:12 ` Stefan Monnier
2009-07-27 0:35 ` YAMAMOTO Mitsuharu
2009-07-27 3:12 ` Adrian Robert
2009-07-29 3:23 ` Sean O'Rourke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AADBBD39-E480-478D-B720-097867734346@gmail.com \
--to=adrian.b.robert@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=mituharu@math.s.chiba-u.ac.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.