Exception when accessing text attributes in echo area buffers

Things that I've seen consistently:

1. The textstorage's "cache" string ("real" NSMutableAttributedString) is consistent with the Hemlock string. In several recent cases where I've seen this, both are empty.

2. The call to attributesAtIndex:effectiveRange: that blows up is made from display code; the (foreign) backtrace shows that the NSLayoutManager is trying to determine text attributes at index 0 and that this was called from NSTextView's drawRect: method.

This suggests that the layout manager isn't picking up on the fact that CLEAR-ECHO-AREA - or something similar - has deleted the echo-area buffer's entire contents.

I think that this has to do with there being a pending #/beginEditing when a view is deactivated; there's then an outstanding #/beginEditing in effect when the view is reactivated, and the display/layout code gets confused.

A text view shouldn't really have any unprocessed editing changes when it becomes active or inactive.

I haven't seen this since implementing the change described in changeset:7046.

There's still some debugging code associated with that change; at one point, I thought that the problem had to do with view activation/deactivation occuring when #/beginEditing was in effect. I'm not sure that that was really the problem, but it's clear that the activation/deactivation needs to occur on the main thread.

Once that issue's resolved - and assuming that the symptom doesn't recur - it'd be possible to close this bug.

It seems to occur much less frequently than it had, but I got the DBG trap associated with it a little earlier today.

As generally seems to be the case when this happens, there was a pending #/beginEditing on the echo-area textstorage when something tried to access character attributes.

I've been trying to find the cause of this (out-of-bounds error in #/attributesAtIndex:effectiveRange: on the hemlock-text-storage associated with an echo area buffer) by finding the command thread for the window and PROCESS-INTERRUPTing it with CCL::DBG (enter the kernel debugger). It seems that HI::CLEAR-ECHO-AREA is always on the stack.

HI::CLEAR-ECHO-AREA calls HI::DOCUMENT-SET-POINT-POSITION, which can cause redisplay. It should presumably do this only if the document's textstorage's change count is 0, but this isn't guaranteed to be the case (we might be modifying the echo area buffer when we decide to clear it; we should only update the display code's notion of where the selection is when we're officially done making changes to the buffer.)

I think that the debugging technique used here (forcing a breakpoint in a window's command thread when the event thread misbehaves) would often catch this sort of thing, because the hemlock command thread will rarely have left the scene of the crime (it'll be waiting for a #/performSelectorOnMainThread:withObject:waitUntilDone: call to return.)

I've seen this less often than I'd been seeing it, but I've been running on a single-processor system for the last several days.

One way to provoke this (that doesn't seem to be timing-sensitive and seems entirely reproducible):

1. Open a new buffer; enter "abc", a newline, a space, and "def".

2. Position the cursor before the space on the second line, then do:

m-x Delete Indentation

3. Blammo.

This seems to have to do with how the text system is notified of deletions.