If implemented properly, the user should not even realize they are working with spaces for indentation, which is one of the greatest pains of a person who prefers tabs for indentation working on a file that has spaces for indentation.

Spaces should be treated as if they were tabs under the following conditions

1. The text editor's insertSpaces setting is true (or leading spaces precede tab characters on a line).
2. The cursor is within the range of leading indentation.
   1. We can't possibly guess where indentation ends and alignment begins, so this includes all leading whitespace (both spaces and tab characters, assuming each tab character is the width of tabSize).
3. The user attempts to do any of the following:
   1. Arrow-key navigation.
   2. Backspace.
   3. Delete.
   4. Mouse selections (more difficult to implement, I'm sure).

Examples of how spaces are treated as tabs

1. If the cursor is at the beginning of the line and the right arrow key is pressed, the cursor jumps tabSize spaces, instead of just one.
2. If tabSize is 4 and the cursor is on position 6 (between tabs) and the left arrow key is pressed, the cursor jumps 2 spaces instead of 4, landing gracefully on a tab stop.
3. If tabSize is 4 and the cursor is on position 4, but the first non-whitespace character is on position 6, then the space on position 5 is assumed to be alignment; thus, a right arrow key press would land on position 5.
4. The backspace and delete keys should eliminate up to tabSize spaces in one batch, so that a single undo operation restores all of the spaces that were deleted.
5. Ideally, mouse selections would also be restricted to tab stops, so you can't individually select the spaces between a single indent.

Exposing an editor setting

• Perhaps an editor setting called navigateSoftTabsAsHard should be exposed for those who wish to opt in or out of this feature. The default value is debatable.