Switching Tab Size to 2 does not insert a tab size of two consistently.

[RaymondLim]

Note that you need to follow all the steps exactly to see the issue.

1. Make sure you have Dennis' "Show Whitespace" extension installed and View >
   Show Whitespace is checked.
2. Quit Brackets and delete Brackets cache, brackets.json and states.json.
3. Open a js file. I used FindReplace.js file from Brackets src.
4. From status bar click on "Spaces:" so that it switches to "Tab Size:".
5. Change the number 4 on the status bar to 2. That is, we want to insert tab (or indent) with two spaces.
6. Set cursor on an empty line after a function definition. If you already have some spaces on that line, hit backspace to delete everything. Your cursor should be on the first column. I used line 95 in FindReplace.js file.
7. Hit tab key. You will see two spaces inserted.
8. Hit tab key again, You get a tab character that takes two spaces.
9. Hit tab key again. You get a tab character that takes four spaces.

If you switch project, then insert tab will be working correctly. That is, it will now insert a tab that takes two spaces for each tab key.

[RaymondLim]

I tried with sprint 33 build and can't reproduce the issue. So this must be introduced with the new preference model. Set it to medium priority for now even though I think it can be high priority since users may not be aware of the inconsistent behavior of the preference change and may unwittingly mess up their documents.

[redmunds]

Good catch! I think part of the problem may be due to this code:

    } else if ((useTabChar && prefName === SPACE_UNITS) || (!useTabChar && prefName === TAB_SIZE)) {
        // This change conflicts with the useTabChar setting, so do not change the CodeMirror option
        return;

I don't think there is any conflict between those settings so they should always be set. For example, you can have USE_TAB_CHAR: false and SPACE_UNITS: 2 if you want to insert 2 space chars when indenting, but you still might have TAB_SIZE: 4 to display any tab chars as 4 spaces.

[TomMalbran]

@redmunds That code is fine. It is there because we use 3 settings (USE_TAB_CHAR, SPACE_UNITS and TAB_SIZE), but CM uses 2 (indentWithTabs and indentUnit). So if the instance has USE_TAB_CHAR: true and you change the value of SPACE_UNITS, you don't want to change the CM option indentUnit, because if you do, you are changing the tab size inside CM.

[njx]

FWIW, someone on Twitter mentioned some inconsistency in tab/space insertion as well a couple weeks ago, but didn't have repro steps.

[dangoor]

I can fix this, unless you want it @redmunds since you're already working in this area.

[redmunds]

@dangoor I had a hunch that appears to be wrong -- it's all yours.

[dangoor]

Oh, reading Raymond's original report more closely, this is not the issue I was thinking it was. It is likely unrelated to the prefs system (as I was initially thinking it would be as well). That's okay, I can still see if I can figure out what's going on.

[RaymondLim]

Reassign it to myself since I found the real cause and the fix.

[dangoor]

Thanks Raymond

[njx]

Fixed by filer, closing