[Openmcl-devel] Hemlock text display
ch-openmcl at bobobeach.com
Sun Aug 29 23:47:55 EDT 2004
For those of who weren't paying close attention, where can we find the
new hemlock sources for use with OpenMCL?
On Aug 29, 2004, at 8:28 PM, Hamilton Link wrote:
>> Aside from paren matching and syntax coloring, is there anything that
>> we should think about
>> adding, like inline controls or something, that might be very useful?
>> COCOA, for example, has
>> the ability to put attachments into the text stream. I can't think of
>> a reason why that would be useful
>> in a lisp IDE, but it might.
> I think the ream of things that are currently spewing undefined
> function warnings may include some good candidates, since they would
> not be getting reimpmlemented (though if there is carving-out involved
> I'd advise against it).
> If it can do a reasonable job of syntax coloring that'd be OK, as long
> as character widths don't get tweaked (my main irritation about this
> feature in whatever init I've loaded into MCL to do this) and as long
> as the guiding principle for coloration is the MDC threshold (Minimal
> Detectable Change -- no vibrant neon or pastel pale gray please).
> 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.
> But that's just it, I don't think it's a great idea to make the
> Cocoa side of things hugely lisp-aware, that's what most of the code
> in Hemlock is there for. Where a little lisp-awareness will go a long
> way to make Hemlock not care about the View, or where the editor can
> be easily made to shortcut stages in Hemlock by invoking its
> functionality via callbacks, swell.
> ___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)
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel