v1.1.9 Patch #9
Closed
v1.1.9 Patch #9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Added the new `logDebugInfo` method to log all debugging information to the Output channel. - Extracted all the debug logging from the `constructor` into it's own method to keep the constructor clean. - Changed the format of the data logged for the supported languages. Instead of logging the `Map`s, we now utilise the auto-generated language definitions files. This is because the single-line languages are reformatted in a human-readable way to output to the file, so it would be better reading this formatted file than the JS `Map`.
- Added the new `logDebugInfo` method to log all debugging information to the Output channel. - Extracted all the debug logging from the `constructor` into it's own method to keep the constructor clean. - Changed the format of the data logged for the supported languages. Instead of logging the `Map`s, we now utilise the auto-generated language definitions files. This is because the single-line languages are reformatted in a human-readable way to output to the file, so it would be better reading this formatted file than the JS `Map`.
This is a work around for the fact that the `vscode.extensions.all` API can't find any built-in extensions on the Windows-side when running in WSL. It only gets the WSL-installed extensions, which caused the extension not to work in #6 There is an open issue and a proposed API change in the sourcecode since 2022, but hasn't been released as a public API. See microsoft/vscode#145307 for more info. Added: - Added new `getExtensionsPathsFromWslEnv` method to retrieve the Windows built-in and user extensions paths from the environment variables when running in WSL. - Added new `readExtensionsFromDirectory` method to read the extensions paths and retrieve each extension data. Changed: - Changed `findAllLanguageConfigFilePaths` method to check if the extension is running in WSL. If it `isWsl`, then it calls the new `getExtensionsPathsFromWslEnv` method to get the paths, and uses the new `readExtensionsFromDirectory` to obtain the extensions data. We construct a new `extensions` array with all the windows-installed built-in and user extensions and also the WSL-installed extensions via `vscode.extensions.all`. (The extension will still work on Windows without WSL due to it using `vscode.extensions.all` outside of the `isWsl` check.) - Changed the `for...of` loop to iterate through the new `extensions` array.
Added: - Added an `isWsl` check, and uses the new `getExtensionsPathsFromWslEnv` method to log the Windows extensions paths from WSL. Changed: - Refactored all "VS Code" items into a new object so that we're not repeating "VS Code" multiple times. This makes for a better reading experience.
This was
linked to
issues
Jul 10, 2025
Added:
- Added new `extensionDetails` private property in `Configuration` as a Map object.
- Added new `setExtensionData` method to set the data into the `extensionDetails` Map. Also added its method call into the `constructor`.
- Added new `getExtensionData` public method to get the value of a specified key from the `extensionDetails` Map.
Changed:
- Refactored `getExtensionNames` to be more generic.
This will be used in the new `setExtensionData` method to get and set the names, id and version into the `extensionDetails` Map.
- Changed the name to `getExtensionPackageJsonData`.
- Changed it's visibility to `private`.
- Changed the reading of the package.json file to use the `readJsonFile` method as it does the exact same thing, and makes it DRYer.
- Added the extension's version.
- Changed all references to the old `getExtensionNames` method to use the new `getExtensionData` method with the specific key needed.
Removed:
- Removed the unused `extensionNames` variable and method call from the `getExtensionsPathsFromWslEnv` method.
Previously we manually created the user extensions path from the home directory env variables and concatenated strings on to it. This is only good if the default extensions directory is used. This will fail if the user has changed the directory location with the CLI `code --extensions-dir <path>` So to fix, we're now getting the user extensions path from where ever this extension is located. The code for this is defined in `setExtensionData` method as committed in 25fab48. - Changed the construction of the users extensions path in `logDebugInfo` to use the `getExtensionData` method to get the path. - Removed the unneeded home directory variables.
- Moved the code to get the built-in extensions path from `logDebugInfo` in to the `setExtensionData` method. - Added the built-in extensions path to the `extensionDetails` Map in `setExtensionData` method. - Updated `logDebugInfo` method to get the `builtInExtensionsPath` key from the Map using `getExtensionData` method.
Added:
- Added the WSL built-in and user extensions paths code to the `setExtensionData` method and set them into the `extensionDetails` with new Map keys.
- Moved the environment variable code to get the WSL-installed user extensions path from the `logDebugInfo` method, and added the `getExtensionData` method call to the log item instead.
- Refactored the `getExtensionsPathsFromWslEnv` method into `setExtensionData` method, simplifying the code.
Removed:
- Removed the now unused `getExtensionsPathsFromWslEnv` method, and changed all references to use the `getExtensionData` with the appropriate key.
In the `setSingleLineCommentLanguageDefinitions` method, it uses the `String.includes` method to detect when the `lineComment` string has `includes` a semi-colon - ;. Apparently the lineComment key in the language config can be either a string or an object. The object has a `comment` key, among others. But because the `includes` method is on the String prototype, when its used on the object, it errors out with "lineComment.includes is not a function". The only language to do this was "makefile". To fix: - Added a check to see if the `lineComment` is an object with a `comment` key inside, if it does then use the string value of the `comment` key. Otherwise, it will use the string value of the `lineComment`.
This was
unlinked from
issues
Jul 12, 2025
Owner
Author
|
Superseded by #12 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.