Custom Query (1030 matches)

This just changed in the last few releases: the foreign constant #$NIL has apparently changed to #$nil. As a result, easygui fails to compile, which causes (require 'cocoa-application) to fail.

The behavior of the return key in the listener in the latest release seems to have changed in a very annoying way. The previous behavior was:

1. If the cursor was on the last line of the listener, and there was

a complete sexpr on that line, that sexpr would be evaluated.

2. If the cursor was on the last line of the listener and there was

not a complete sexpr on that line, a newline would inserted.

3. If the cursor was anywhere else in the buffer, the sexpr to the

left of the cursor would replace the last line in the buffer. (IMHO, this was not the correct behavior. The correct behavior is what Fred used to do: append the sexpr to the left of the cursor to the last line. But that's another issue.)

The new behavior, as best I can make out, is:

1. If the cursor is at the end of the buffer (not merely on the last

line) and there is a complete sexpr to the left of the cursor then the sexpr is evaluated. This is as it should be. However...

2. If the cursor is on a line other than the last, then the sexpr on

that line is copied to the last line AND it is evaluated. This is badly broken IMHO because there is no opportunity to edit the line. Now to re-use a previous line of input with changes you have to select, copy, click, and paste. Very annoying. Worse...

3. If the cursor is on the last line but not at the end of the line,

then a newline is inserted. In addition, if there was a complete sexpr on the last line, it is evaluated. However, the cursor does not drop down to the new last line. It stays where it is. This is just b0rken. It's particularly annoying because there's a bug in the listener scrolling code so that if you do this at the bottom of a window, you get output that you don't see unless you manually scroll the window down.

I'm rating this "major" because it's really messing me up, especially the last item.

? (time (print (make-string 10000)))
""
(PRINT (MAKE-STRING 10000)) took 11,157,608 microseconds (11.157608 seconds) to run 
                    with 2 available CPU cores.
During that period, 10,291,164 microseconds (10.291164 seconds) were spent in user mode
                    868,038 microseconds (0.868038 seconds) were spent in system mode
70,577 microseconds (0.070577 seconds) was spent in GC.
 97,616 bytes of memory allocated.
 120 minor page faults, 12,281 major page faults, 0 swaps.
""

Note that the above was run with string highlighting disabled. When it's enabled, things get even slower. (See ticket #540.)

It would also be nice (and would be a resolution of this ticket as far as I'm concerned) to have something like *print-length* that applied to strings. I'm doing some database work that involves very long strings (megabytes) and it would be very nice not to have to manually kill the printing process whenever I accidentally print one of these monsters.

I'm calling this a "minor enhancement" because I can work around it myself by defining a print-object method on strings.