[Openmcl-devel] Hemlock ain't Fred

[Gary Byers]

On Tue, 30 Oct 2007, Ron Garret wrote:

>
> On Oct 30, 2007, at 4:23 AM, Gail Zacharias wrote:
>
>> I see you found the answer, but just a caveat: I'm working on
>> changing all this.
>
> FWIW, here's some feedback on the IDE.
>
> First, let me say that the current state of things seems to me to be
> 90% of the way there already, so most of these comments are pretty
> minor.  But Fred set the bar mighty high :-)  So here's my list of
> gripes:
>
> 1.  When typing a sexpr, matching-paren highlighting does not happen
> as you type.  Instead, the matching paren only starts to flash a
> second or two after I stop typing.  This really slows me down.

I think that there's a bug for this in trac.  Yes:

<http://trac.clozure.com/openmcl/ticket/64>

I think that it actually starts the paren blinking as soon as the
insertion point gets drawn/starts blinking, but the paren blinks
in the wrong phase relative to the insertion point.
>
> 2.  Double-clicking on a close-paren doesn't do the right thing when
> the close paren is the last character in the file.
>
> 3.  If you evaluate a sexpr from an editor buffer and generate an
> error, cmd-. doesn't pop out of the debugger.  You have to go back to
> the listener, type cmd-., then go back to the editor.

I think that cmd-. works if either a listener window whose listener
is in a break loop or a backtrace window is active.

It could probably be made active if an editor window is foremost
and that editor has enqueued something to a listener that caused
the listener to enter a break loop ... I dunno.
I guess that it could also be active if -some- listener is in a
break loop, but most of the menu items related to controlling
a listener process are really "targeting" the listener process
associated with a particular listener window.

>
> 4.  Monaco 9 is the One True Font, but it looks horrible in bold under
> OS X.  It would be nice to have a separate font selection for Lisp-
> generated output in the listener instead of just bolding the default
> font.

It's synthesized (there really isn't a "Monaco Bold"); there -is-
a Courier Bold (that's antialiased and doesn't look as smudgy.)

But yes, there should be some way of selecting the style used
for listener output.

>
> 5.  Calling hemlock-interface::delete-characters doesn't work and
> eventually results in a hard crash (but you probably knew that already).

See my long message from last night (and Gail's message of around the
same time.)

>
> 6.  There are a few features that currently appear to be missing which
> I'm sure are easy to do and which are in the pipeline, but just to
> help you prioritize, the ones I miss most are: meta-point, macroexpand-
> current-sexpr, and command-key bindings for eval-buffer and backtrace.

Meta-. should work pretty well; I don't understand this.  (Maybe
it's not picking up the symbol, or doesn't find symbols defined
in buffers that don't have filenames associated with them ?)

I didn't remember what keys macroexpand and macroexpand-1 were
bound to, so I did (in an editor, not a listener window):

C-h

echo area prompted for Help: , I typed "a" for "apropos"

echo area prompted for "Apropos what:" (in so many words), I typed
"macroexpand"

A popup window showed defined editor commands that contained
"macroexpand" in their names and the keys that they were bound
to.  (Not much better than "better than nothing", but better than
nothing.)  Note that there is a bad bug related to typing to
one of these popup windows, and I tried this in a listener
and the listener went comatose, apparently unsure as to whether
the main view or echo area view was active.

eval-buffer used to be bound to Cmd-H, which now invokes "Hide
Application".  If there was an "eval buffer", it'd pretty much
have to have a command-key equivalent that didn't conflict with
that ("Hide Application/cmd-H" is an aqua standard thing.)

Backtrace is cmd-shift-b.  If there was a font menu, cmd-b would be
"Bold".  cmd-shift-b is active if the "target" window is a listener
and that listener thread is in a break loop.


>
> 7.  If the listener point is not at the end of the buffer, then the
> results of evaluating a sexpr using the enter key don't appear for a
> very long time (many seconds) and sometimes not at all until you
> scroll the listener window up and back down.

Hmm.

>
> 8.  In both the listener and editor windows, the enter key doesn't
> work if the current sexpr is atomic.

Don't understand this.

>
> 9.  Clicking on a previous input in the listener and hitting "return"
> copies the entire input sexpr instead of just the one corresponding to
> the current selection.  And clicking on previous output and hitting
> return or enter does nothing unless the output is actually selected.
>
> Other than that I love it.  I'm happily hacking Lisp again for the
> first time in years.  Woot!
>
> (There are some aspects of the new IDE that actually improve on MCL,
> e.g. immutable text in the listener window.  That's definitely the
> Right Thing.)

People who don't like it can set a preference.
>
> rg

It helps to get feedback, but (if you can) please create an account
for yourself (this partly discourages spam) at 
http://trac.clozure.com/openmcl and enter bugs there.

It's also really desirable (if you want to use the IDE regularly)
to try to stay up-to-date via CVS and rebuild the lisp regularly.
(if this makes no sense, we'll try to ensure that something somewhere
accurately documents the process and refer you to that.)


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