[mac-lisp-ide] Portable Hemlock and questions

[Gary Byers]

On Thu, 22 Jul 2004, David Steuber wrote:

> These are just some idle questions.
>
> Is the source from Hemlock at all useful as far as editing functions
> for porting over to a proper Carbon based application for an Aqua
> compliant IDE?

I had made some progress in integrating Portable Hemlock and Cocoa;
I'd hoped to be able to release that a few  months ago, but haven't
had time to do much of anything OpenMCL- or mac-lisp-ide- related
since.

I don't know how useful this would be to someone determined to use
Carbon.

Hemlock is strongly oriented towards a model where a single "frame"
(in the Emacs sense; this means something like "window" to the rest
of the world) displays multiple buffers.  I had tried to get things
to fit better into the Mac "document" paradigm: so that there'd be
roughly a 1:1 correspondence between a Hemlock buffer and a Mac
document (and generally a single document per window.)  I'd managed
to nudge a lot of Hemlock towards the Mac paradigm, but there was
still a lot of nudging to do (some Hemlock commands/functions still
think that it's involved in redisplay and layout, and don't behave
correctly under Cocoa.)

I think that it's fair to say that Hemlock's not very thread-aware,
and some of the things that I did to try to make it behave better in
a multi-window, multi-threaded environment are incredibly ugly. I
suspect that many things have to be at least fairly ugly: "modal"
things (like M-X and incremental search) want to block for input,
but you don't really want the whole IDE to freeze because some
window is waiting for the next incremental search character ...

As far as Hemlock itself goes ... I still think that it's easier than
writing an editor core would have been, and it provides lots of support
for S-expression-based navigation out-of-the-box.  Aside from the
whole "who's in charge of event-processing and redisplay" issues, the
biggest piece of missing functionality that I can think of in the
Hemlock code base is support for pattern-based searching (e.g., to
be able to have M-. find a DEFUN or DEFMETHOD pattern without getting
confused by case-sensitivity, whitespace, and other details.)

I think that most of the functionality that Hemlock provides is
reasonable (if a bit spartan), and that the major difficulties with
using Hemlock in a modern Aqua environment would be shared most other
starting points (e.g., if you re-wrote [X]Emacs in CL, you'd still
have to think about document/buffer/frame issues and threading and
modality and ...).

If anyone wants to volunteer to fix up/finish the Hemlock/Cocoa stuff
I started, I can help some; I hope to be able to work on it more in
the near future, but every prediction I've made so far about how "near"
has proven wildly optimistic.