[Openmcl-devel] What is the state of the phemlock included with OpenMCL?

[David Steuber]

On Jul 31, 2004, at 10:11 AM, Gary Byers wrote:

> On 31. Jul 2004, at 08:59, David Steuber wrote:
>>
>>> I'm interested in having a go at porting hemlock to run as a Carbon
>>> application.  Which sources should I use?

> Note that "integrating Hemlock with Cocoa" probably isn't a matter of
> replacing CLX code to handle redisplay/scrolling with Cocoa/Quartz
> equivalents; the idea was and is to use Hemlock as a backend to the
> Cocoa text system and get all of that system's redisplay/scrolling/
> selection support for free.  (It's not free, but it's probably a
> lot closer to free than starting from scratch would be.)

I'm not yet familiar with OS X's text management stuff.

> I suspect that if someone wanted to "integrate Hemlock with Carbon"
> (why?), they'd face a similar set of issues: you'd either want to
> leverage existing text-management and display technology (MLTE)
> or try to handle all of these things yourself.

The reason I am thinking Carbon is it seems more flexible.  I could be 
wrong about that.  By flexible, I mean that a CLOS wrapper doesn't have 
to be forced into the Cocoa model.  Also, the way the Cocoa bridge 
stands currently, distributing a binary only works for people on the 
same revision of OS X.

May I ask why Cocoa was chosen over Carbon?

> The fact that the development in the main phemlock tree is concerning
> itself with backends that aren't just drawing engines and raw event
> sources (as CLX is) is potentially good news.  I don't know whether
> this could or would lead to a Hemlock whose "backend"
> (buffer-management code, command processing, etc.) was independent of
> one of several drop-in replacement frontends
> (CLX/CLIM/MLTE/Cocoa/...).  That strikes me as being an attractive
> long-range goal, but I don't know how easy it would be to achieve in
> the near term (those "frontends" aren't exactly orthogonal or
> equivalent in terms of the functionality that they offer.)

To be honest, I wasn't thinking in terms of portability.  I figured 
Hemlock would already know how to do various Emacs like commands wrt 
editing and navigating Lisp source files.  I'm not after something 
portable so much as saving work making something for OS X that is Aqua 
compliant but still offers Emacs like power.

If X11 was the target, then portability would be more of a concern I 
guess.  Heck, Emacs has done a heck of a job being portable to all 
sorts of windowing systems, not to mention a plain terminal.  I have 
Carbon Emacs from CVS running on my PowerBook.  It is still obviously 
pre-alpha, but it is surprising how much it is beginning to look like 
the X11 version.  It is also quite useable.

> I got the Hemlock/Cocoa stuff that I was working on up to a certain
> barely-usable to worth-criticizing level of functionality (a lot of
> stuff works, some stuff doesn't, and there are still lots of bugs,
> both big and small.)  I haven't been able to work on it for a few
> months, and honestly don't know how soon I'll be able to.  I'd
> personally rather try to encourage anyone who's intrerested to try
> to finish this (and to offer what help I can) than to suggest that
> someone start from scratch.

It's possible that we have different goals.  But starting from scratch 
is something I want to avoid which is why I'm asking about hemlock in 
the first place.  I've never written an editor before and know nothing 
of the theory behind text editors like Emacs at all.