[Top][All Lists]

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

Re: Mac OS-compatible ports

From: Adrian Robert
Subject: Re: Mac OS-compatible ports
Date: Sun, 1 Jan 2012 15:31:45 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Jan Djärv <jan.h.d <at> swipnet.se> writes:

> 1 jan 2012 kl. 02:54 skrev
>   YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>:
> > 
> > What about the "Lisp evaluation inside read_socket_hook" problem
> > on the GNUstep port?  Is your idea for Cocoa (Mac OS X 10.5 or
> > later) applicable to GNUstep, or do you have another idea?
> If GNUstep provides the same API, it is applicable, but I have to get
 GNUstep up and running first to check.
> Their documentation says no, but that might not be up to date.
> But I'm sure some solution can be found. It does not need to be the same
> as for OSX. 
> On another note, could your font backend be plugged in in Emacs 24?  Would it
> be worthwhile?

In principle it should be possible to plug in pieces from some of
the font backend function implementations.  It would necessitate
ifdefs for GNUstep.  One way to make that cleaner would be simply
to split the backends for GNUstep and MacOS, using a superclass
for common functionality, similar to W32 and X.

As far as read_socket_hook, there has been a lot of discussion of
this in the past.  Yamamoto-san has always insisted there is an
irremediable design issue in the NS port, but I've never been
convinced of this, preferring to target and fix individual
problems.  Not sure if either of us can be 100% objective
though. ;-)

Still, when I last looked at this (years ago now), it seemed like
it would be possible to switch the event loop approach without
large-scale code changes.

One aspect which I don't remember the status of is multi-TTY.  I
remember at one point the Mac port wasn't working with it.  Is
that still the case?  If so is it a design issue relating to the
event loop approach or something that could be fixed?


reply via email to

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