Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/11/07, Stefan Monnier <address@hidden> wrote:

> I do hope that it's somewhat limited to the redisplay and that the rest of
> the Carbon-Emacs effort (unrelated to UI) will be preserved.  But to tell
> you the truth, I do not know what that amounts to, so for all I know,
> there's nothing left to preserve there.

The Cocoa and Carbon ports share about as much code as any other pair,
e.g. X11 and W32.  It would be like if the GTK port and the X11 port
were first created independently without using either of each others'
code.  Except that, additionally, the Cocoa port (higher level, like
GTK) cannot use the Carbon port's code even if it wants to now,
because these APIs are not available under GNUstep.

In the reverse direction, I'm not sure whether Carbon-Appkit was able
to take much from the Cocoa port, or if the constraints of its own
architecture made this impractical.

There's not much code in the ports that's NOT related to UI, which is
the way it should be (*), but where there is, e.g. Andrew Choi's Mac
unexec module, the Cocoa port uses it.

(*) Generally a lot of code is shared between all ports.  E.g. X11,
Carbon, and Cocoa all use the same code for parsing lisp menus into
widget_value structures.  I split this into nsmenu_common.c (1000
lines), but did not modify xmenu.c or macmenu.c to use it.  There's a
line between refactoring of this kind that simplifies maintenance
(less understanding of emacs internals needed by window system coders,
less identical code in multiple files to keep in sync) and that makes
things too inflexible for some ports to easily work with, but IMHO
there's a lot more that could be done.  Though in a large project like
this, it's not easy.


-Adrian