[BUG]: Pressing Ctrl+/ uses /**/ instead of //

[mbomb007]

Describe the bug
When in PHP and having this module enabled, if I press Ctrl+/, it uses /**/ style comments instead of just adding // to the start of the line. This is quite an annoying change from the default behavior.

To Reproduce
Steps to reproduce the behavior:

1. Go to a PHP file
2. Click on a line of code
3. Press Ctrl+/
4. Do the same without the module enabled.

Expected behavior
A clear and concise description of what you expected to happen. The behavior should be the same as it was before. There's no reason to use a multiline comment for a single line.

Additional context

Log file

[yCodeTech]

This is directly related to #6 where the extension doesn't get the language files from the built-in language extensions on Windows from WSL.

---

There are 2 ways the Ctrl + / can use /**/ comments instead of //:

1. When the language ID was added to the multiLineStyleBlocks custom support setting but not the slashStyleBlocks, VS Code has a built-in fallback for those languages that don't specify a single-line comment style. This means that if it doesn't have a single-line style, but does have a multi-line style, then the keybinding will automatically use the multi-line style instead. (CSS is case in point).
   Though from the log, this isn't the case as PHP is defined in both settings.

2. When the extension can't find the language file (like currently on WSL) of a custom supported language defined in the settings, the extension uses a default multi-line config as defined in:

auto-comment-blocks/config/default-multi-line-config.json

Lines 2 to 4 in a376ba7

	"comments": {
	"blockComment": ["/*", "*/"]
	},

But this is only for /**/ style block comments, and no default for single-line comments is defined. The VS Code API can only override the existing configuration and not modify it, so the language will only end up having those defaults without any other configuration files to help fill it out.

Ultimately, the language configuration is a map from language id to configuration which ends up overwritten by the later extensions.
~ microsoft/vscode#73798 (comment)

Then VS Code will end up using the block comments for single comments as explained in number 1. above.

Note

It's also worth noting that PHP is a special case, as I'm sure you're aware, the file can interpret 4 different languages: PHP, HTML, CSS, and JS. VS Code has to do some magic based on the scripting tags to determine what language to use for comments. So VS Code will only use PHP comments via the keybinding inside <?php ?> tags.

---

I have installed WSL2 Ubuntu and using the settings as output in the log, I can only replicate this issue outside of the <?php ?> tags. Inside the tags, it correctly uses the // for me with the Ctrl + / keybinding.

However, I have a working fix for the overall WSL issue, and I hope to roll out a release soon.

[mbomb007]

I have installed WSL2 Ubuntu and using the settings as output in the log, I can only replicate this issue outside of the tags. Inside the tags, it correctly uses the // for me with the Ctrl + / keybinding.

None of my PHP code is outside of the tags.

It'd be nice if maybe there was also a setting that if no language configuration can be found, then use VS Code's settings that exist without the module installed.

[yCodeTech]

It'd be nice if maybe there was also a setting that if no language configuration can be found, then use VS Code's settings that exist without the module installed.

I can't replicate this issue anymore in my PR, so I don't think this is necessary. If after the new release (hopefully this week), and you still think this setting is needed, I will add it in the next release. But for now, I'll close this issue.