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
I don't think it makes that much sense logically speaking. One advantage I can see is that you don't have to remember the setting name, but I don't think that it's such a big one, at least because you can auto-complete "path" to find what the path name is.
An advantage with different path keys is that you can more easily switch out debugger types by simply changing the type. You would not put /bin/gdb into lldbmipath, but if everything is debuggerPath, that would implicitly happen if you before configured GDB, but now want to change to LLDB.
Ideally the debuggers should be interchangeable without any special configurations for each debugger backend, but realistically all of them have some slighty different featuresets and quirks that it's easier to simply adjust on that. Especially because LLDB actually seems to transition away from full MI support and there not being many other debuggers which implement the MI interface.
But I think it would make sense to have an additional debuggerPath / miDebuggerPath property like you suggested, but that one being the fallback behind the more specific per-debugger settings as well as mentioning the per-debugger configurations in its description. This way one can use the regular debuggerPath with a custom debugger and test through the different types (although that is a very niche use-case) as well as configuring debuggers per-type like they were actually intended.
This is mostly a question @WebFreak001, but a general response won't harm either.
Currently we have different settings for the debugger path, depending on the debug configuration.
It is either
gdbpath
,lldbmipath
ormagomipath
.I suggest to either drop those completely (hard break) or at least only use them as fallback for a new setting.
Suggested new name:
debuggerPath
or (that would follow the MS debugger extension)miDebuggerPath
.Opinions?
The text was updated successfully, but these errors were encountered: