[Openmcl-devel] Hemlock text display

[Hamilton Link]

> 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)

h

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