[Openmcl-devel] IDE laundry list

[Ron Garret]

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

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.

rg