You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 1, 2024. It is now read-only.
I refer to PR #1183 which provided the feature of auto-generating c_cpp_configuration.json to the vscode-arduino extension.
The auto-generation of the config file is a welcome one and saves effort in preparing an Arduino workspace. However, editing the config file after its generation can sometimes lead to the auto-generator triggering on (re-)startup, leading to duplicate/redundant string values within the file.
Version Information
OS used: Windows 10 (10.0.19042)
VS Code: 1.54.1 (user setup)
vscode-arduino: 0.3.5 (master)
Relevant for later report on steps taken as well as suggestion:
ms-vscode.cpptools: 1.2.2
I retested steps 1-3 but only changing one string's separators to / at a time, leaving the other relevant strings with \\ separators and deleting the redundant strings, with similar results as above.
I changed the setting "C_cpp: Preferred Path Separator" (C_Cpp.preferredPathSeparator in settings.json) from the default 'Forward Slash' to 'Backslash' thinking that it may be related to the issue. This did not affect the results of subsequent retests, and I reverted this change on my settings.
Impact
This does not appear to have any significant performance impact other than additional startup time for VS Code to write in the auto-generated lines. However, this does impact on code uniformity especially since other string values such as for the compilerPath key are accepted and do not trigger the auto-generator even with the / separator.
Suggestions
To have an extension setting for path separator preference similar to the setting present in ms-vscode.cpptools, allowing the user to choose between the Unix/Mac / or DOS \\ separators, or rely on system/default settings instead.
To have an extension setting for the auto-generator to be bypassed/ignored, or only trigger if there is no c_cpp_configuration.json in the workspace.
When parsing c_cpp_configuration.json on setup, have relevant string values with alternate separator characters be recognised as valid and not trigger the auto-generator as a result.
Thank you for reading this admittedly long issue post and hope that this situation can be improved.
The text was updated successfully, but these errors were encountered:
I refer to PR #1183 which provided the feature of auto-generating c_cpp_configuration.json to the vscode-arduino extension.
The auto-generation of the config file is a welcome one and saves effort in preparing an Arduino workspace. However, editing the config file after its generation can sometimes lead to the auto-generator triggering on (re-)startup, leading to duplicate/redundant string values within the file.
Version Information
OS used: Windows 10 (10.0.19042)
VS Code: 1.54.1 (user setup)
vscode-arduino: 0.3.5 (master)
Relevant for later report on steps taken as well as suggestion:
ms-vscode.cpptools: 1.2.2
Configuration File Used
I am including the file as a code block below:
Steps Taken
Ctrl+H
) I replaced all instances of\\
with/
. The changed parts of the file would beand
/
at a time, leaving the other relevant strings with\\
separators and deleting the redundant strings, with similar results as above.C_Cpp.preferredPathSeparator
in settings.json) from the default 'Forward Slash' to 'Backslash' thinking that it may be related to the issue. This did not affect the results of subsequent retests, and I reverted this change on my settings.Impact
This does not appear to have any significant performance impact other than additional startup time for VS Code to write in the auto-generated lines. However, this does impact on code uniformity especially since other string values such as for the
compilerPath
key are accepted and do not trigger the auto-generator even with the/
separator.Suggestions
/
or DOS\\
separators, or rely on system/default settings instead.Thank you for reading this admittedly long issue post and hope that this situation can be improved.
The text was updated successfully, but these errors were encountered: