[Top][All Lists]

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

Re: Emacs on OS X development

From: Jan Djärv
Subject: Re: Emacs on OS X development
Date: Sun, 5 Aug 2012 14:51:38 +0200

3 aug 2012 kl. 22:28 skrev Adrian Robert:

> 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.

I agree with the points below.  The main issue with the NS event loop is that 
it doesn't redraw on resize.  But besides that, I think it can be improved to 
the point of being good enough for both OSX and GNUStep.

The NS font backend works, its main problem is that it uses some old deprecated 
methods.  Bringing in the Mac port font end is a more modular operation, and 
does not have much impact.

        Jan D.

> 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]