Open jonahgraham opened 23 hours ago
How would a possible use case look like?
A user opens a C/C++ source file in the old C/C++ editor. Codan/parser finds an error and creates a marker. One quick-fix would be to switch on the Set C/C++ (LSP) Editor as default
flag only. But this would imply that all files for the given project/workspace opened in the old editor has to be closed and re-opened in the LSP based editor? Then clangd (maybe) offers a quick-fix for the problem?
Or is the use case that the "LSP quick-fix" should be displayed only when there are no other quick-fixes available?
The idea is that we have lots of markers being created because of parse errors in "old" cdt. I want to provide visibility to those users that lsp is available. And yes, the quick fix (which will start a short wizard) will reopen editors.
Does that sound reasonable to you?
Does that sound reasonable to you?
yepp, but I would suggest that vendors can disable this quick-fix. This would be necessary when the new editor should be used by customers only for certain C/C++ project types (e.g. not for old managed build projects without compile_commands.json file available). Maybe we can introduce a check via extension point which asks if a given project supports the new editor.
When codan or parser finds an error one of the quick-fixes should be to switch the project or workspace to using the
C/C++ Editor (LSP)
so that users can discover that the CDT LSP implementation resolves their problem.PR incoming for this.