emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pretest next week


From: YAMAMOTO Mitsuharu
Subject: Re: Pretest next week
Date: Tue, 14 Jul 2009 12:32:50 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Sun, 01 Feb 2009 09:34:06 -0500, Chong Yidong <address@hidden> said:

> YAMAMOTO Mitsuharu <address@hidden> writes:
>> If you want to start the pretest soon, I suggest putting off the
>> inclusion of the Cocoa/GNUstep port until Emacs 23.2 (or later).
>> In particular, the GNUstep port doesn't have enough quality to
>> start pretest.

> That would be counter-productive.  Consider the worst-case scenario
> of keeping the Cocoa port: suppose that, just before the 23.1
> release, the port remains as irretrievably broken as you make it out
> to be.  In that case, we can disable it by changing the build
> system, and mark it as experimental/hackers-only.  So nothing is
> lost by keeping the port (and I am optimistic that it will not come
> to that).

Now I suppose we are at "just before the 23.1 release".  Will the NS
port be marked as experimental/hackers-only, or given a title of
"first-class" port as a part of the official release?

Besides stability/performance issues found in the bugtracker, it still
has several compatibility issues as I mentioned earlier (I added new
comments in brackets in the following):

1. Different interface for existing functionality.

  a. ns-read-file-name vs. x-file-dialog
  b. ns-drag-{file,color,text} event + own handlers vs.
     drag-n-drop event + dnd.el
  c. ns-expand-space vs. line-spacing frame parameter
     [No longer an issue: the former was removed.]
  d. nsfont_make_fontset_for_font vs.
     :lang/:script/:registry properties in font-spec
     [The former is removed, and :lang/:script support was added, but
      :registry support is still missing.  The ns font-backend driver
      doesn't have the "shape" function for Complex Text Layout.]

2. Interface is the same, but implementation is based on own interpretation.

  a. tooltip (not being an Emacs frame, it cannot make use of Emacs
     display features such as images.)
  b. selection concepts (local/foreign selection, ownership)
  c. rightmost scroll-bar placement (it doesn't consider the case
     where scroll bars in different width, e.g., C-x 2 M-:
     (set-window-scroll-bars nil 11 t) RET)
  d. internal-border-width
  e. fringe and cursor drawing

3. NS-only implementation for features that are not inherently specific to NS.

  a. preferences panel
     [No longer an issue: removed.]
  b. alpha-component in color specification
     [Even without alpha, many formats in the NS port are incompatible
      with the other platforms.  The only compatible one is #rrggbb,
      which is not encouraged according to the X11 man page.  In this
      sense, it can also be classified as Group 1.]
  c. color image for stipple (cf. tiling patch by Miles Bader)
     [Even for monochrome images, "stippling" in the NS port is
      actually implemented as tiling rather than stippling.  In this
      sense, it can also be classified as Group 2.]

4. Suspected fundamental design flaw.

  a. C-g handling
  b. menu bar activation timing

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]