Disabling "Use Tab Stops" should be respected in more indentation contexts

Type: Bug

I work a lot in C / C++ / Fortran code that uses different indentation amounts in different constructs. For example, the body of a function / subroutine might be indented by 2 spaces for the top-level indentation, but other blocks (bodies of conditionals, loops, etc.) are indented by an additional 4 spaces. I'd like to have indentation set at 4 spaces so it works right in most places, and then have VSCode always indent by an additional 4 spaces relative to the previous line, no matter what column the previous line was on, both with the automatic indentation when hitting enter after starting a block, and with use of the tab key. Instead, VSCode seems to always want to indent to a "tab stop" - i.e., a multiple of 4 spaces in an absolute sense from the left margin - in these two situations.

It seems like the "Use Tab Stops" setting is designed to control this behavior. And indeed, disabling this setting leads to correct / expected behavior when running the "Indent Line" command ("Cmd-]"), leading this command to always insert 4 spaces (or whatever the tab size is set to). However, disabling this setting seems to have no impact on automatic indentation or the behavior of the tab key. It seems that the behavior of both automatic indentation and the tab key should honor "Use Tab Stops" similarly to the "Indent Line" command - i.e., indenting by a fixed amount relative to the previous line (or, stating that differently: the tab key should insert a fixed number of spaces), not based on tab stops.

I have reproduced this issue in a fresh installation of VSCode Insiders with no extensions (adding the C/C++ extension pack does not change this behavior), where I have changed only two settings: Disabling "Editor: Use Tab Stops" and disabling "Editor: Detect Indentation".

To reproduce this:

(1) From a fresh installation of VSCode, change two settings: Disable "Editor: Use Tab Stops" and disable "Editor: Detect Indentation".

(2) Create a C file with the following contents (note that indentation of the existing content uses 2 spaces):

#include <stdio.h>

int main()
{
  int x = 0;

  printf("%d\n", x);

  if (x == 0) {
  }

  printf("%d\n", x);
}

(3) Change indentation to use spaces and change the tab display size to 4 if not already set that way.

(4) Position the cursor after the { at the end of line 9.

(5) Hit "enter". Notice that the cursor is now at column 5; I would expect it to be at column 7 based on these settings of "Use Tab Stops" disabled and a tab display size of 4.

An alternative reproducer is to do the same steps 1-4 but with "Editor: Auto Indent" set to "keep", and then:

(5) Hit "enter". The cursor should be at column 3 (as expected).

(6) Hit "tab". Notice that the cursor is now at column 5; I would expect it to be at column 7 based on these settings of "Use Tab Stops" disabled and a tab display size of 4.

Here are screencasts demonstrating this issue:

First, here is a screencast where "Editor: Auto Indent" is set to "keep". I positioned the cursor after the { at the end of line 9, then hit "enter" and then "Cmd-]" to run "Indent Line". This exhibits what I would consider the correct / expected behavior:

https://github.com/user-attachments/assets/d7e9dc97-50be-415f-bf98-18f216003710

Second, here is a screencast where "Editor: Auto Indent" is still set to "keep". I positioned the cursor after the { at the end of line 9, then hit "enter" and then "tab". This incorrectly indents to column 5 instead of column 7 (the second version of the reproducer above):

https://github.com/user-attachments/assets/16df9403-e5fb-4423-9d69-e9ac7f466289

Third, here is a screencast where "Editor: Auto Indent" is reverted to its default ("full"). I positioned the cursor after the { at the end of line 9, then hit "enter". This again incorrectly indents to column 5 instead of column 7 (the first version of the reproducer above):

https://github.com/user-attachments/assets/b30bd07f-f5bc-4a71-8eb6-b35711f9c6b9

Note that the indentation will later be fixed if a formatter is enabled (e.g., after typing the semicolon at the end of the line if "Format on type" is enabled), but the behavior of auto-indentation and the tab key should honor "Use Tab Stops" without relying on a formatter.

VS Code version: Code - Insiders 1.94.0-insider (Universal) (8b7eb51f54d7e1492d9baf70454ab6547a4ff9df, 2024-09-10T05:04:21.546Z) OS version: Darwin arm64 23.5.0 Modes:

System Info

|Item|Value| |---|---| |CPUs|Apple M1 Pro (10 x 2400)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled
webnn: disabled_off| |Load (avg)|5, 7, 7| |Memory (System)|32.00GB (0.05GB free)| |Process Argv|| |Screen Reader|no| |VM|0%|

Extensions: none

A/B Experiments

``` vsliv368cf:30146710 vspor879:30202332 vspor708:30202333 vspor363:30204092 vscod805cf:30301675 vsaa593:30376534 py29gd2263:31024238 c4g48928:30535728 a9j8j154:30646983 962ge761:30841072 pythongtdpath:30726887 welcomedialog:30812478 pythonnoceb:30776497 asynctok:30898717 dsvsc014:30777825 dsvsc015:30821418 pythonmypyd1:30859725 2e7ec940:31000449 pythontbext0:30879054 accentitlementst:30870582 dsvsc016:30879898 dsvsc017:30880771 dsvsc018:30880772 cppperfnew:30980852 pythonait:30973460 bdiig495:31013172 a69g1124:31018687 dvdeprecation:31040973 dwnewjupytercf:31046870 newcmakeconfigv2:31071590 nb_pri_only:31057983 nativerepl1:31134653 refactort:31084545 pythonrstrctxt:31093868 flighttreat:31119334 wkspc-onlycs-t:31132770 nativeloc1:31118317 wkspc-ranged-c:31125598 3ad50483:31111987 jh802675:31132134 e80f6927:31120813 ei213698:31121563 ```

microsoft / vscode

Disabling "Use Tab Stops" should be respected in more indentation contexts #228286