[Openmcl-devel] hemlock

[Gary Byers]

On Tue, 3 Aug 2004, alex crain wrote:

> I'm interested in working on the hemlock integration. Can you give me a
> 100 word description of where things are?
>

1) get the latest 0.14-dev sources from CVS checked out into someplace
other than your main ccl directory.  Install the interfaces and binaries
(the 0.14.2-p1 versions should work) in that new directory.

(optionally) re-build the lisp image & kernel from sources; this should
be just about identical to 0.14.2-p1 + bug fixes from cvs.  The resulting
image will identify itself as "0.14.2-040506", which reflects both the
fact that I haven't done much on it in a few months and the fact that
dates like that only come along every century ...

2) Start up that lisp and do:

? (require "COMPILE-HEMLOCK")

? (CCL::COMPILE-HEMLOCK t)

That'll compile a few dozen files in "ccl:hemlock;src;" and produce
a few dozen warnings (some of them fairly ominous-looking.)

When the process finishes, it'll concatenate the Hemlock fasl files
into a single large "ccl:library;hemlock.dfsl".

(For extra credit: replace CCL::COMPILE-HEMLOCK with an ASDF system
or something less ad-hoc.  That may be overkill at this point, but
I've forgotten to recompile HEMLOCK after making changes.)

The sources in "ccl:hemlock;" are derived from Gilbert Baumann's
phemlock sources as of late 2003.

3) Either in that same lisp image or subsequently, do:

? (require "COCOA")

The Cocoa sources now require HEMLOCK (and this should load the large
hemlock.dfsl created earlier.)

The bridge still takes a long time to import class and method information
from the libraries.

As in the "traditional Cocoa demo IDE", you should eventually get a
listener to appear.  There's a funky little "preferences" dialog (whose
menu key equivalent should probably be changed to "cmd-," in IB.

Hamilton Link's inspector should work in this environment (you'd have
to require "COCOA-INSEPECTOR"), but it isn't integrated with the
listener/editor/backtrace dialogs.  (Yes, there's a backtrace dialog.)

There's generally a -bit- more functionality in the listener and editor
buffers than there was in OpenMCL's original Cocoa demo (matching parens
blink, and there's basic S-expression-based navigation and selection.)

There's no on-line help on key bindings (which are similar to but not
identical to Emacs or FRED key bindings); the source file "ccl:hemlock;
src;bindings.lisp" at least describes the editor commands associated
with key bindings.

4) brief architecture description:

The basic idea (suggested by Mikel Evins) is to base the storage layer
of the Cocoa text system (NSTextStorage and NSMutableAttributedString)
on Hemlock buffers.  Apple's Cocoa documentation describes the protocol
that user-implemented NSTextStorage subclasses need to implement: there's
not a whole lot to it.  The text system tries to view the underlying
"string" as a simple linear array; Hemlock buffers are doubly-linked
lists of "line" structures, so there's a simple (too simple) caching
mechanism to map between buffer indices and (line, char-offset) pairs.

On the Hemlock side of things, there are a relatively small number of
primitives (INSERT-CHAR, DELETE-REGION, etc.) that actutally modify
the buffer (and therefore modify the text system's text-storage object).
Changes are bracketed by "beginEditing/endEditing" messages, and
announced by "edited:range:changeInLength:" messages.  I -think- that
all of the buffer-modification primitives do the right thing, but they
may do so over-zealously (it may be better to defer updates a little
longer in some cases.)

For a variety of reasons, the current code tries to contribute to
a "document-based" application: there's generally assumed to be
at most one window per buffer and generally at most one buffer per
window.  There are some arguments in favor of a more traditionally
Emacs-y (or Hemlock-y) view of the roles of buffers windows and
documents, but I think that the arguments in favor or a Mac-like
UI are stronger.

There's currently (very) limited support for multiple fonts in
the same buffer (listener output is normal, listener input is bold).
I'd started to do some work on generalizing this, but more work needs
to be done.

In general:

- each Hemlock window has its own thread and is mostly unaware of
  other threads/windows/buffers.  That thread basically processes
  key events (received on a thread-private queue), interprets those
  key events as editing commands, executes the command (notifiying
  the text storage system of any resulting changes in the buffer)
  and repeats the process.)

- the main Cocoa event thread receives key events from the window
  system and passes them to the window thread.  In addition, it
  handles buffer-change notifications from the per-window threads.

The general division of labor is that the per-window threads handle
buffer changes and the main event thread handles display issues; there's
some reason to suspect that this may be overkill.

Aside from feeling guilty for not having thought about it, I haven't
thought much about undo/redo.


5) Overall

- there are still bugs; there are still vestiges of CLX display code
(the actual CLX code should be commented out, but there are still
pieces of code and data structures that assume that Hemlock will
have a more active role in redisplay than it does in this scheme.)
There are some functions/editing commands that still call this
vestigal code.

- a lot of stuff works (and some of it works well).  It's generally
possible to write Lisp code to implement an editing operation without
being aware of the details of the event/display mechanisms, and that's
a good thing.

- there are plenty of other things - both good and bad - to be said,
but I'm already way over the 100 word limit ...

> Also, could you see if I'm on the openmcl-devel mailing list? I was
> once, but I changed my address from alex at widgetworks.com to
> alexcrain at widgetworks.com and while I tried to subscribe a couple of
> times, I'm not getting any mail.

>From here, widgetworks.com seems to have DNS problems (no MX record,
no A records ...).

I added you, but the confirmation message seems to be stuck in clozure's
mail queue.

>
> :alex
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>