Expose a Way to Determine if a User Changes Thier Text Document Language Using the Language Mode Option in the VS Code UI

[browntarik]

We are currently working on the C++ Extension on adding behavior that will correctly identify the textDocumentLanguage of an extensionless file that is opened using a C++ extension feature. We are running into an issue where when we use the vscode.languages.setTextDocumentLanguage() when we first open a file, we overwrite any language mode that is selected through the UI in the bottom right.

We want to be able to detect whether the textDocument for a file was set using this option so we do not overwrite it. Is there an existing way to identify this? If not, would it be possible to add a flag to determine if this is how a textDocument language was set?

This is in reference to microsoft/vscode-cpptools#4077

[Colengms]

In C/C++, whether a ".h" file should be interpreted as C, C++ or even CUDA, depends on what other file(s) include that file.

The C/C++ Extension will leverage an 'include graph' to determine an appropriate source file to use, and the header file will be interpreted in the context of that source file. (The source file is used to build the IntelliSense Translation Unit). This is also useful in order to configure IntelliSense properly, as configurations from custom configuration providers (CMake Tools, Makefile Tools), or compile_commands.json entries (these are how we connect to build systems), will be associated with source files, rarely header files.

Currently, we automatically change the file association of that header file (using setTextDocumentLanguage) to match the source file we've selected. However, we'd like to 'respect user intent'. If a user has explicitly selected a language for a header file, we'd like to honor that. Unfortunately, doing so would require us to identify whether or not the current language association is a result of explicit user intent, or a default. While it would be possible for us to check files.assocation settings, there is not currently a way (that we know of) to detect if the user has selected a language using the pop-up menu at the bottom of the window (or the 'Change Language Mode' command).

This ask is for an API that indicates if the user explicitly selected a language to associate a file with vs. using a default (or otherwise auto-corrected) association. If we detect that an explicit selection was made, we could choose an appropriate language source file (if available) that matches that language, in the scenario I described above, instead of considering the entire include graph.

A secondary issue here is that the setTextDocumentLanguage establishes only a temporary association. It gets reset between sessions. This requires us to implement code to persist when we change a file association, if we want that association to continue to be applied in a subsequent session. (We're trying to remove code that emits files.assocations settings in similar scenarios, as that is less ideal.)

A tertiary issue is that setTextDocumentLanguage seems to have equal priority vs. the UI pop-up (or 'Change Language Mode' command). Whichever is set last takes priority. Alternatively, it would be useful to be able to set the language mode in a way that retains a lower priority than any user-initiated mechanism, so it may never override 'user intent'. (Though, I can also imagine an extension needing to set the language as a result of user intent.)

[vs-code-engineering]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vs-code-engineering]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vs-code-engineering]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!