[Openmcl-devel] IDE laundry list
ron at awun.net
Sun May 17 14:40:01 EDT 2009
Finally got around to trying out 1.3 and all in all I have to say it
is much improved, good enough that I may actually go back to using
Lisp for a real project for the first time after many years of
wandering in the Python desert. There are, however, a few things that
I consider, um, annoying deviations from the behavior that I came to
know and love under Fred. I'm putting them in an email because most
of these don't really qualify as bugs (but a few do) and are largely a
matter of taste. So I'm posting this to the list to see if other
people feel the same way I do.
1. This one actually qualifies as a bug, and I believe there's a long-
standing ticket open on it: When you double-click on a close-paren
that is at the end of a buffer, the corresponding S-expression does
not get selected. Instead, what happens depends on the character
immediately to the left of the close-paren. If that character is
itself a close-paren, then the S-expression corresponding to *that*
close-paren is selected, otherwise the final close-parent character
itself is selected.
2. In my old MCL environment I had a function key bound to a function
that pretty-printed the macroexpansion of the current sexpr. I used
that almost as much as meta-point, maybe more, and I really miss it.
I get the feeling that if I dug deeply enough I could figure out how
to add this myself, but I would really like to see it be a standard
part of CCL.
3. Selection collapsing is not done properly. (I believe someone
else mentioned this here not too long ago, but I'm including it on my
list for completeness.) Apple's UI guidelines are very specific on
what happens when you hit various keys while there is an active
selection. The behavior of the CCL GUI doesn't seem to follow any of
them. In fact, it is hard to figure out exactly what the actual
behavior even *is*. As near as I can tell, if the current selection
is a sexpr, then the cursor goes to the beginning of the selection,
plus or minus one character depending on whether the selection was
collapsed with the left or right arrow. If the selection was not a
sexpr then the same thing happens except the cursor goes to the end of
the selection instead of the beginning. This is annoyingly random.
Also, if the selection is collapsed with the return key, the current
selection should be replaced by a newline, but instead the selection
is collapsed before inserting a newline. (This one should be really
easy to fix because the behavior for regular characters seems to be
4. The behavior of the return key in the listener is also annoying.
Hemlock seems to make a stronger distinction between input and non-
input areas of the listener than Fred did. If the cursor is in an
input area, then the contents of that input area replaces the contents
of the bottommost input area, regardless of whether or not there is a
current selection. If the cursor is in a non-input area then it
simply returns to the end of the buffer. And if there is a current
selection in a non-input area then it extends the current selection to
the end of the buffer (!). The Right Behavior, IMO, is something
closer to what Fred did: regardless of whether the cursor (or current
selection) is in an input area or non-input area, when you hit the
return key, the current selection (if there is one) or current sexpr
(if there isn't) should be ADDED to the current input at the end of
the buffer, not replace it.
5. The new way of balancing parens is not bad, a vast improvement
over the way it was before, but it would be nice to be able to
customize the highlighting. In particular, I'd like to be able to
change the color. That cyan doesn't resonate well with me for some
reason. Even better, I'd like to be able to change both the
background color *and* the color and style of the glyph (in which case
I'd probably choose for the background color to be white, and
highlight matching parens by making them bold, but that's just me).
That last one is a pretty minor nit though.
If all these things -- or even just the first four -- were fixed then
I would be a very happy hacker indeed.
More information about the Openmcl-devel