wrong .editorconfig applied

[mcandre]

When launching VSCode via code <path>, it seems to forget to apply either WSL home's ~/.editorconfig or native Windows home's ~/.editorconfig.

Unsure if VSCode forcibly translates /mnt/c paths to C:\ paths. In any case, the plugin should trampoline configuration files based on the nearest user home directory to the given workspace launch path.

[sl-devops-us]

Update:

The problem occurs, even when both WSL and native Windows have the same ~/.editorconfig contents:

https://github.com/mcandre/dotfiles/blob/main/.editorconfig

Never encountered this problem on macOS.

Curious if this is a Windows specific bug. Or perhaps some VSCode and/or EditorConfig plugin configuration state glitch.

How agnostic is the VSCode EditorConfig plugin in terms of line terminators and final EOF presence/absence, of the .editorconfig itself?

[SunsetTechuila]

How agnostic is the VSCode EditorConfig plugin in terms of line terminators and final EOF presence/absence, of the .editorconfig itself?

should be fully agnostic

could you please provide step-by-step instructions on how to reproduce the issue?

[aep-sunlife]

Update

This glitch triggers for two common cases:

• Pre-save, when VSCode has a file open but has not activated Ctrl+S / Command+S
• Zero byte files, such as those freshly allocated by touch <path> in WSL

In both cases, EditorConfig should force VSCode to treat the files as LF (according to our .editorconfig). However, the plugin currently lets VSCode's default of CRLF appear in the status bar. Which is really confusing to users.

Regarding zero byte, empty files, that is an interersting case for EditorConfig. Particularly for anyone linting with automated EditorConfig tools. I believe zero byte should be preserved, instead of forcing a final EOL, even when a final EOL is configured. This optimizes disk space, for file trees involving millions of empty files. In any case, a zero byte file should be interpreted to already match the preferred terminator (e.g., CRLF or LF), even though neither the \r nor \n rune are present. And so the status bar should always show the configured termination style, for zero byte files, as if such a sequence were present in the file.