implemented textarea behavior #235

Merged
merged 2 commits into from May 30, 2012

Projects

None yet

2 participants

@hallahan
Contributor

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

@WardCunningham
Owner

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
Contributor

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
Contributor

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 WardCunningham merged commit 301cb8c into WardCunningham:master May 30, 2012
@WardCunningham
Owner

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
Owner

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
Contributor

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

@WardCunningham
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment