implemented textarea behavior

[hallahan]

Text area's caret goes to end when active. Backspace with caret at position 0 now concats with prev item.

[WardCunningham]

Caret-to-end means that I can't delete an unwanted split. I'm working on a merge, adding a few more checks, and reverting this one change.

[hallahan]

The backspace at the beginning of a text area allows you to delete unwanted splits. What goes wrong when the caret is at the end of text areas by default?

[hallahan]

I think I know what you are talking about. Perhaps I could have the caret go to the end only on double click so that splits will have the caret at the beginning to facilitate an easy rejoin.

[WardCunningham]

Yes, I think that is what is bugging you. I've reverted this change because I didn't want the other behavior. Have a go at making it right. Thanks.

[WardCunningham]

I've found another issue with this commit. It doesn't distinguish that the content is merging is of the same type. That means accidental merges can't recreate the accidentally merged item by simply typing return.

I've also noticed that selecting a word at the begining of a paragraph and deleting it is incorrectly interpreted as requiring a merge. This should delete only the word, not the word and the split in front of it.

I've also noticed that items of type "calculator" split when returns are entered. This is unwanted behavior for calculator where returns are part of the domain-specific calculator language.

[hallahan]

Wow, lots of problems. I will begin tomorrow resolving this. I will carefully play with my fix.

[WardCunningham]

More than we could think of in advance but not a lot by any means.