emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs on OS X development


From: Adrian Robert
Subject: Re: Emacs on OS X development
Date: Fri, 3 Aug 2012 16:28:10 -0400

I think Jan is closer to the event-handling code than I have been lately, so 
I'd rely on his judgment as to whether what I'm saying is accurate or 
realistic, and how it could be carried out.

Also, merging this code would just be a way to improve the current NS port for 
users, it is not an answer to whether the Mac port should replace it, etc. 
etc..  (Which has already been covered in this thread as well as we can cover 
it for now.)

thanks,
Adrian




On 2012/08/03, at 16:08, Ted Zlatanov wrote:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.devel as well.
> 
> On Tue, 31 Jul 2012 14:31:30 -0400 Adrian Robert <address@hidden> wrote: 
> 
> AR> As far as a merge, one way would be to bring in the event-handling
> AR> from the Mac port to the NS port.  When I looked at this it seemed
> AR> practical, but would be a fairly intense effort, say 5 full-time days,
> AR> probably an underestimate since a solution for GNUstep would need to
> AR> be maintained.  Then there would also be the text rendering.  Since
> AR> that is more modular, it might be possible to bring in Yamamoto's
> AR> backend almost whole as a compile-time option.  I also don't think the
> AR> current NS backend has that many deficiencies, but for whatever reason
> AR> they've stayed there (text shaping, line spacing, font selection).
> 
> AR> The second merge option would be to rework portions of the Mac port to
> AR> more heavily utilize the Cocoa APIs, to the point it could be ifdef'd
> AR> to run on GNUstep.  Yamamoto could provide the best assessment here,
> AR> but my feeling when I looked at it was that it would not be easy.
> AR> Definitely more work than going the other way.
> 
> Based on your and Mitsuharu-san's reply, I think merging his work into
> the NS port is the better path rather than trying to bring the Mac port
> into the Emacs tree.  If you can define the work necessary to do the
> event handling and text rendering rework, plus the other specific
> features of the Mac port that are missing in the NS port, that would be
> a helpful TODO list for any contributors.
> 
> Thanks
> Ted




reply via email to

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