I could not think of a better title so will attempt to explain myself better here. Currently, the IDLE smart backspace will delete multiple whitespace up to the tab width even if it is not at the start of the line. Consider the following examples (where the | is where the cursor is when backspace is clicked - the backticks are just to show code not part of the example text):

`    |abc  def  `: IDLE correctly deletes all four spaces as this is considered the indentation of the code.

`    abc  |def  `: IDLE incorrectly deletes both spaces rather than just one (annoying when correcting a typo). The patch proposes IDLE just deletes one space as is normal/expected behaviour.

`    abc  def  |`: IDLE will currently delete both spaces but the proposed patch will just delete one. This behaviour is up for debate as I personally think all trailing whitespace should be cleared by a backspace, but I also think the proposed behaviour is more consistent than the existing behaviour.

The patch (a PR to be linked shortly after issue creation) is very simple as we already have the compiled `_line_indent_re` which we can check for a full match on all text before the cursor (`chars`).

Further clarification on the new behaviour: in the shell whitespace after the prompt (>>>) will not be considered an indent and only have one character deleted at a time. However, on a continuation line, any initial whitespace will be considered an indent and the smart backspace behaviour will apply.

Your example is 4 spaces, 3 (non-space) chars, 2 spaces, 3 chars, 2 spaces.
With the cursor after the 2 internal spaces, backspace deletes 1 space, not 2.  However, with the first block expanded from 3 chars to 4, backspace deletes both spaces.

Without out looking at the code, the uniform rule, when deleting a space to the left with Backspace, seems to be "Delete up to Indent spaces, stopping at the first non-space char or at a slice position that is a multiple of Indent."  Tabs in the text are interpreted as as many spaces needed to get to a position that is a multiple of 8.  I tested this with longer space runs and with Indent set to 5.

Deleting a space with Delete always deletes one char.  So single space deletion is available anywhere.

I consider the current behavior as a defensible design decision for a PEP 8 oriented Python code editor.  Multiple space deletion is a plus when deleting large space blocks, a minus when lining up multiple continuation lines.  While I could imagine turning off multiple space delete for internal blocks, I would rather trailing blocks be deleted all at once.  All in all, I consider a change fairly low priority at the moment.

The prompt is 4 chars: '>>> '.  Anything after that is an indent and should be treated as such.  It is the first line of a mini 'file' with one statement.  Treating this line differently would be a bug.

I have updated the PR for the following two suggestions:

> I would rather trailing blocks be deleted all at once
> Anything after [the prompt] is an indent and should be treated as such

Again, consider the following examples (apologies about the last ones: I have learnt the lesson - always test your examples!). All examples use the default indent width of 4:

8 spaces; cursor - This is currently deleted in blocks of 4 and the patch will not change this behaviour (an indent takes precedence over trailing)

4 spaces; 4 chars; 8 spaces; cursor - As the trailing whitespace is no longer also the indent, all 8 spaces will be deleted

1 char; 2 spaces; cursor; 1 char - This behaviour of the original patch has not changed: the spaces get deleted one at a time

In the process of testing this patch, I stumbled across another bug which is, if a continuation line is changed to start with the prompt, IDLE will refuse to delete it. Simple example: type `\`; return; backspace; `>>> `; backspace. I have prepared a branch which resolves this by setting a text mark at the start of the last prompt line and checking for that when refusing to delete prompt characters (if you would like me to create an issue and PR for this).

Tests are needed.  See review.

Thinking about tests makes me realize that we need to extract an EditorText class that has the methods that only apply to the text component of EditorWindow.  That is most of them.  This would make testing easier because there would be no need to create a window to test the text methods.