Virtually all text editing programs on all platforms use the same algorithm for arrow keys and text selection, however Kdevelop deviates from this standard convention. The context is that you have a block of text selected, and you press an arrow key (without holding SHIFT) so that the block becomes deselected. The question is, where does the cursor go next? For most programs, pressing the unshifted right arrow causes the cursor to appear at the end of the block, while pressing the unshifted left arrow causes the cursor to appear at the beginning of the block. (You can try this right now in your browser in any text edit field.) For Kdevelop, however, pressing either left or right arrow causes the cursor to appear at whichever side of the block the cursor previously moving. (In other words, the end of the block which is not the anchor.) This may seem like a trivial issue, but it actually messes up my typing quite a bit. Reproducible: Always
That's Kate/KTextEditor behavior and probably around for years. As I only use that editor, I'm probably biased. I think either behavior is fine, and being compatible with other editors is also a good idea sometimes. I'll let Christoph and Dominik decide on whether to change KTextEditor behavior or not.
*** Bug 323947 has been marked as a duplicate of this bug. ***
Yeah, this caught me too when I started using Kate as my primary text editor. Regardless of the merits of KTextEditor's selection philosophy, there's a huge value in following common comventions, and I think this selection behavior issue qualifies. No other text fields or text editor that I'm aware of behave like this. My vote would be for changing it to be consistent with other software.
*** This bug has been marked as a duplicate of bug 296500 ***