[Openmcl-devel] Hemlock text display

[Gary Byers]

On Sun, 29 Aug 2004, Hamilton Link wrote:
>
> I know there are callback functions that support querying a model to
> determine how much of what to select at a time so it might be possible
> to do sexp selection from the Cocoa components by calling back into the
> paren-matching code directly instead of solely going through Hemlock's
> key bindings.

The selectionRangeForProposedRange:granularity: method tries to select
the nearest adjacent list if you're immediately before or after a
paren in a lisp "section", and falls back to standard Cocoa selection
otherwise.  Currently, Hemlock's buffer-parsing code is invoked on
every double-click; that's not grossly inefficient, but if the Cocoa
side of things (the layout manager, at least) had more of knowledge of
the lisp structure of the buffer (and of how editing changes affected
that) it might be better.

>
> ___However___ I'd personally like to see what exists already made to
> work well before we start to make it fancy. The speed demon that is now
> Hemlock has a panic sheet that pops up whenever I look at the screen
> funny, and I'd like the sources of those occurrences to be eliminated
> first. Then I'd like to be able to easily invoke the inspector,
> backtrace, etc. and _then_ we can add neat doohickies to the IDE, and
> we'll have a lot better idea where the shortcomings are and what the
> user base is hot to have. (right now it seems to me that there is no
> user base because there are too many editor-generated errors, first
> things first eh? as soon as we have enough users to have one other than
> me realize the inspector stinks I'll fix it, right now I can't hardly
> stand editing code)
>

Agreed, in principle.  Note that the backtrace window is fairly easy
to invoke; the menu option (command-shift-B, on the Lisp menu) is
active if the frontmost window is a listener and that listener's
in a break loop.  It's (slightly) better than nothing.


> h