'\t' does not match tab character in custom problem matcher

[i-ky]

Issue Type: Bug

Here is my tasks.json file:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "tab",
            "type": "process",
            "command": "echo",
            "args": [
                "-e",
                "foo:42:<bar\\tbaz>"
            ],
            "problemMatcher": {
                "pattern": {
                    "regexp": "^(.*):(\\d+):<(bar\\tbaz)>$",
                    "file": 1,
                    "line": 2,
                    "message": 3
                },
                "applyTo": "allDocuments",
                "fileLocation": "autoDetect",
                "source": "testing"
            }
        }
    ]
}

I expect this task to produce a new problem in Problems tab, because echo -e '\t' outputs a tab character and \t regexp patter should match it (I assume VS Code uses Javascript regexp flavour). But this is not the case. Seemingly tab characters are replaced with spaces before problem matcher is applied. If regular expression is replaced with a more permissive one:

                    "regexp": "^(.*):(\\d+):<(bar.*baz)>$",

...then task successfully creates a problem. If you go to Problems tab and Copy Message you will see that it contains a number of spaces instead of a single tab character:

bar     baz

VS Code version: Code 1.57.1 (507ce72, 2021-06-17T13:28:07.755Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No
Remote OS version: Linux x64 4.19.128-microsoft-standard

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (4 x 3192)
GPU Status	2d_canvas: unavailable_software gpu_compositing: disabled_software multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: disabled_off rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: unavailable_software webgl2: unavailable_software
Load (avg)	undefined
Memory (System)	15.93GB (4.68GB free)
Process Argv	--folder-uri=vscode-remote://wsl+Ubuntu-18.04/home/developer/VOL --remote=wsl+Ubuntu-18.04 --crash-reporter-id 9aa49be5-1cf5-44e6-9504-f9cdf52b0acb
Screen Reader	no
VM	0%

Item	Value
Remote	WSL: Ubuntu-18.04
OS	Linux x64 4.19.128-microsoft-standard
CPUs	Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (4 x 3191)
Memory (System)	9.73GB (4.74GB free)
VM	0%

Extensions (23)

Extension	Author (truncated)	Version
jq-syntax-highlighting	jq-	0.0.2
remote-containers	ms-	0.183.0
remote-ssh-edit	ms-	0.65.7
remote-wsl	ms-	0.56.5
sourcetrail	ast	0.0.2
vscode-modelines	chr	2.0.5
ssh	chr	0.0.4
vscode-graphviz	joa	0.0.6
svn-scm	joh	2.13.6
vscode-docker	ms-	1.14.0
csharp	ms-	1.23.12
python	ms-	2021.6.944021595
vscode-pylance	ms-	2021.6.3
jupyter	ms-	2021.6.999662501
cmake-tools	ms-	1.7.3
cpptools	ms-	1.4.1
vscode-commons	red	0.0.6
vscode-xml	red	0.17.0
graphviz-interactive-preview	tin	0.0.11
cmake	twx	0.0.17
docker	vsc	1.0.0
yaml	vsc	1.0.0
vscode-ansible	vsc	0.6.0

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383cf:30185419
pythonvspyt678:30270856
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551cf:30311713
vspre833:30321513
pythonptprofiler:30281270
vshan820:30294714
pythondataviewer:30285071
vscus158:30321503
pythonvsuse255:30323308
vscorehov:30309549
vscod805:30301674
pythonvspyt200cf:30331938
vscextlang:30322306
binariesv615:30325510
vsccppwtct:30329789
aatestflight:30331711

[alexr00]

I think this is a property of terminals. @meganrogge can terminal output contain tab characters?

[meganrogge]

I do not know. @Tyriar?

[Tyriar]

Tabs cannot exist in the terminal, what a tab does is advanced the cursor up to 8 characters (depending on the terminal's configured tab width). For problem matchers a tab would probably either show up as nothing 1+ spaces, I'm not 100% sure.

[i-ky]

Tabs cannot exist in the terminal

As I understand, you are referring to xtermjs/xterm.js#734 (mentioning to link issues, maybe it will help someone in the future).

For problem matchers a tab would probably either show up as nothing 1+ spaces, I'm not 100% sure.

Unlike reporters of #29523, #85878 and #117760, I don't care how xterm.js renders tab characters. It's a pity that problem matchers can't get the original command output. Well, if it "as designed" then it would be nice to mention this caveat in documentation, because it may affect other control characters as well.

Thank you all for fast response!