[Openmcl-devel] Hemlock text display
hamlink at comcast.net
Sun Aug 29 23:50:46 EDT 2004
Excellent question! As your reward, you are my first guinea pig.
Please read the email I just posted for section 2.2. on what to get and
where to get it. It *should* answer your question and if it doesn't I
need to know so I can fix the problem.
Hmm... I just looked at my docs and I think I need to add the following
line to the intro:
To build the stable 0.14 version, read sections 2.2.1.--2.2.3.
For the bleeding-edge 0.14-dev version, also read section 2.2.4.
+ To build Hemlock and the IDE use the 0.14-dev version, also read
If you have to go through a firewall, see section 2.2.5.
On Aug 29, 2004, at 9:47 PM, Cyrus Harmon wrote:
> 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
>> 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
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel