WSL2: config ignored

[thomas725]

I'm using VS-Code with it's WSL feature which mostly works fine but markdownlint sadly ignores all config possibilities I've tried so far:

• "markdownlint.config" block in C:/Users/my-user/AppData/Roaming/Code/User/settings.json
• "markdownlint.config" block in project-root/.vscode/settings.json
• project-root/.markdownlint.json

The problem does not exist in workspaces that don't use WSL but have their files directly in Windows.

[DavidAnson]

I do not have experience with using VS Code to connect to WSL, so don't have suggestions. The fact that you report everything works properly outside of WSL suggests your configuration is valid and the problem is with VS Code's WSL integration. The first two of the three files you list above are VS Code configuration files, so if the editor cannot even recognize its own configuration, that leads me to believe the same limitation applies to markdownlint accessing the third configuration file.

[thomas725]

maybe this docs page could help: https://code.visualstudio.com/api/advanced-topics/remote-extensions this page says the WSL connection is a kind of remote connection: https://code.visualstudio.com/docs/remote/wsl

[DavidAnson]

This documentation page outlines some restrictions and there are a few sections within that might be helpful to you. I skimmed it and some of the linked references and nothing stands out to me as obviously being an extension problem, though the separation of local and remote settings seems relevant to your scenario.

https://code.visualstudio.com/docs/remote/wsl

[thomas725]

tried copying my "markdownlint.config" block to the vscode config file inside WSL = /home/user/.vscode-server/data/Machine/settings.json and restarted vscode afterwards, sadly this did not change the observed behavior.

[DavidAnson]

My suggestion would be to open Settings via the VS Code UI (switching to JSON view if desired). When opening files directly, there is a chance to pick the wrong one.

As far as I know, this extension did and does work with remote workspaces. You can verify that by visiting the following page in your browser, pressing ".", and then installing the extension. Running JavaScript code is not supported remotely (as the warning will tell you), but parsing of JSON configuration in the project toot should be fine and you should see that project configuration is honored when you do the above.

https://github.com/DavidAnson/vscode-markdownlint

[DavidAnson]

I have confirmed the extension behaves as I describe above with a remote repository via VS Code/web.

[thomas725]

Hey @DavidAnson ! Thank you for confirming the issue and sorry for not replying again last week. I did open the file via the VS Code UI, But giving the path was the easiest way I found to specify where I landed in text form here ;)

Is there any workaround I could try or anything else I could do to help get this fixed?

[DavidAnson]

Maybe you can check if other extensions can be configured as you are attempting to do so? If they don't work as you expect either, this may have to do with VS Code itself.

[thomas725]

I am using cSpell for spell checking and have additional accepted words in both workspace repository/.vscode/settings.json and user C:/Users/user/AppData/Roaming/Code/User/settings.json which both work fine.

[DavidAnson]

Maybe configuration is a distraction - .markdownlint.json should work regardless. Can you link to your project? What makes you think that file is not being used? What output shows up in the "markdownlint" tab of VS Code's Output window? Is anything relevant in any other tabs? Does this reproduce on another machine or for anyone else? Are you mixing "/" and "" characters anywhere?

[thomas725]

Sadly .markdownlint.json doesn't work either. I'm trying to disable some rules. My repository/.markdownlint.json reads:

{
    "MD010": false,
    "MD012": false,
    "MD013": false
}

And my problem view is full of MD010/no-hard-tabs: Hard tabs [Column: 1] Interestingly, changing .markdownlint.json makes them disapear until I switch back to a *.md file containing tabs.

Linking my project here is not possible, it's my private Dendron note taking workspace.

[DavidAnson]

Please have a look and share the VS Code Output window info I reference above. I don't use WSL, so I can't try this myself. But you say it works fine on the same repository without WSL, so something about that seems likely to be the problem.

[thomas725]

It only shows one line:

[10:38:14 AM] INFO: Linting for "file:///home/user/encrypted-mnt/Dendron/notes/currently-open-file.md" will be run "onType".

Reloading the VS-Code Window empties it. Modifying .markdownlint.json prints:

[11:28:21 AM] INFO: Re-linting due to "/home/user/encrypted-mnt/Dendron/.markdownlint.json" change.

So apparently it does see the configuration, but ignores it's content...

[thomas725]

I've rechecked: On my native Linux desktop I don't have this problem. .markdownlint.json is read and works fine. It's non-empty existence does overwrite the markdownlint.config block I have in .vscode/settings.json so it prevents those settings from taking effect. Removing the contents of .markdownlint.json did first make the .markdownlint.json I had in a subdirectory take effect, removing this one too makes the settings from .vscode/settings.json take effect.

[DavidAnson]

Thanks for checking that! It sounds like everything behaves as expected everywhere except via WSL? Maybe I can set that up somewhere myself to try, but otherwise I'm not sure what's different about the WSL environment.

[thomas725]

Maybe there's some setting somewhere while developing / building the vs code extension where you can choose weither to run on the windows client side or the wsl back end side. Toggling that around to the other option might help?

https://code.visualstudio.com/docs/remote/wsl says:

Note: If you are an extension author and your extension is not working properly or installs in the wrong place, see Supporting Remote Development for details.

[DavidAnson]

That's a good idea, thanks!

The most relevant-seeming suggestion there is something that you can apparently try out yourself right now. Have a look at the setting described here and maybe try both modes with your scenario to see if it helps: https://code.visualstudio.com/api/advanced-topics/remote-extensions#incorrect-execution-location

It looks like I may be able to use CodeSpaces to test a scenario I haven't tried before (that's described near the top of that page), but I think remote.extensionKind holds the most promise for what you report.

[thomas725]

I can try on Monday, so in 2 days. sorry. I don't have that windows machine with me at home..

[DavidAnson]

Great, thanks, no rush!

FYI, I tried the steps described at https://code.visualstudio.com/api/advanced-topics/remote-extensions#debugging-with-github-codespaces and found that creating test.md and .markdownlint.json worked as expected, so I still have not seen the problematic behavior myself.

[thomas725]

strange, so it's not a general remote problem, but either WSL specific or even something more specific to my machine...

So I'm back on my Windows10+WSL machine, and seeing very strange behavior. It seems to work and load my settings fine using this:

"remote.extensionKind": {
  "davidanson.vscode-markdownlint": ["workspace"]
}

But changing it to this:

"remote.extensionKind": {
  "davidanson.vscode-markdownlint": ["ui"]
}

doesn't give me any markdownlint warnings at all (also not the expected ones I haven't disabled in my config.

I would have guessed one of them should look exactly like having none of them, since vscode should need to decide to run it either here or there even without choosing myself...

UPDATE: removing the block again (+ reloading the window as I did with the other changes) looks like it's working the same as with the "workspace" block now. Next I'll leave it removed and restart vscode for real and see if I can reproduce my bug from before like that...

UPDATE2: really strange. Even completely cold starting vscode without either version now behaves like with the "workspace" block in my user settings.json. Setting it to "ui" prevents the extension from showing any warnings at all.

Extra strange: Now it's a different specific warning that's bugging me even when trying to disable it completely - though as far as I understand it this should not show unless its "strict" mode is set to true (and even then it could be worded better ^^):

MD009/no-trailing-spaces: Trailing spaces [Expected: 0 or 2; Actual: 2]