Custom Query (1030 matches)

After some number of operations that write to/clear the echo area, I sometimes see an exception logged:

NSMutableRLEArray objectAtIndex:effectiveRange:: Out of bounds

This seems to occur when #/attributesAtIndex:effectiveRange: is called on the textstorage object associated with an echo-area buffer; the hemlock buffer seems to be non-empty, but the parallel mutable attributed string has length 0.

I'm not sure what (hemlock stream operations ?) causes them to get out of sync.

Sometimes this seems to be recoverable; other times, it doesn't.

Backup files in Cocoa have names of the form "foo~.lisp". Whatever advantage this may have over the Emacs convention (backup files have the same extension as the original) seems to be outweighed by the disadvantage (backup files have the same extension as the original), so things like "grep FOO *.lisp" require extra effort and things like filename completion get unnecessarily confused.

I don't know how to influence the naming convention, but we can probably bypass the automatic mechanism and figure out how to rename the original file (when applicable) just before saving. (There may be issues with preserving Finder aliases and such unless this is done carefully, but I assume that it's doable.)

(In short, I vote for "foo.lisp~" ...)

A break loop message references :-commands. Those commands are in effect in the IDE, but menu-based equivalents are often available.

> Break: interrupt signal
> While executing: FD-INPUT-AVAILABLE-P, in process Listener(4).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Return from BREAK.
> Type :? for other options.

Certainly the 3rd line could be changed to something like:

> Type cmd-/ to continue, cmd-. to abort, cmd-\ for a list of available restarts.

possibly using the Apple clover-key character instead of "cmd".