Change interactive window behavior when typing inside readonly area #5339
Conversation
Affected operations including: - Delete (and TypeChar) - Backspace - Return - Cut - Paste
Here's the new behavior for all deletion without selected text related operations: - if caret is in editable area, no change in behavior. - if caret is in active prompt area, move caret to the closest location first. - if caret is in other readonly area, do nothing. Here's the new behavior for all deletion with selected text related operations: - if the selection overlaps with editable area, caret will be moved to a position in editable area that is closest to it's original position. - Otherwise, do nothing (and preserve the selection). Deletion related operations including: - Delete (and TypeChar) - Backspace - Return and BreakLine - Paste - Cut
|
@amcasey @tmat @cston @KevinH-MS @ManishJayaswal Please review. This is not completed, I will add tests in later commits. Just wanna send out a PR so we can discuss if this new behavior makes sense. By the way, here's another PR which fix this issue differently (move caret to closest editable location first if it's not originally) #5287 |
|
@tmat Have you reviewed the lastest commit as well? I have changed the behavior of |
|
Looks reasonable. Would need to play with it to see if everything is actually good. |
| if (CutOrDeleteSelection(isCut: false)) | ||
| { | ||
| MoveCaretToClosestEditableBuffer(); | ||
| } |
| var index = GetSourceSpanIndex(sourceSpans, point); | ||
| if (index == sourceSpans.Count) | ||
| { | ||
| index--; |
There was a problem hiding this comment.
@amcasey Well, GetSourceSpanIndex returns the length of the collection if the point is at the end of the last span. Are you suggesting that the prompt will never be in the last span?
There was a problem hiding this comment.
That's true in practice, but we probably don't want to depend on it. I'm very surprised to learn that GetSourceSpanIndex behaves that way, but it looks like all callers handle it.
|
👍 |
|
test full please |
Change interactive window behavior when typing inside readonly area
|
FYI @ManishJayaswal @kuhlenh @tmat @amcasey @cston @KevinH-MS |
Fix issue #5130
Here's the new behavior for all deletion without selected text related operations:
Here's the new behavior for all deletion with selected text related operations:
editable area that is closest to it's original position.
Deletion related operations including:
Delete(and TypeChar)BackspaceReturnandBreakLinePasteCutQuestion:
InsertCodemethod also depends onCutOrDeleteSelectionmethod, but I'm not sure if this change will affect it, can I assume the caret will always in editable area whenInsertCodeis called?