[Openmcl-devel] Hemlock text display

[Hamilton Link]

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 
section 2.2.4.
   If you have to go through a firewall, see section 2.2.5.

h

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?
>
> Thanks,
>
> Cyrus
>
> 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)
>>
>> h
>>
>>> :alex
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>