WebFreak001
Question: How to "properly extend" this extension?
Is it possible to "extend" another extension?
I'd like to make some language identifier specific adjustments (for gnucobol, which is not in the list of languages that this extension handles) where the backend would not use direct mi commands to query the variables and their data or to set conditional breakpoints, but instead execute normal GDB commands with -interpreter-exec console and parse their result (because extensions can't provide new MI commands which is a work-in-progress that may land in GDB12).
So I wonder how to do this best: just fork, then add gnucobol (or possibly cobol) language identifier, then check on frontend requests which language is active, pass that to the backend and do the changes there?
Would there even be a possibility to "extend a debug extension" (kind of "only overwrite specific parts")?
as a debugger is a separate process (debug adapter) that is run outside the vscode extension host, you can't really manipulate it with extensions. To support breakpoints just fork and PR here, that's something that can be added universally. For language specific stuff that's probably outside the scope for PRs.
It might be possible to add some kind of plugin API to code-debug though, which extensions can register into by writing files to some specific location.
I worked around these limitations with my D extension by providing my own debug type, which just runs code-debug (or others) then and injects preload scripts. You can see the source here: https://github.com/Pure-D/code-d/blob/84b7d6bb2b2c0d9fd912722e8d57a36a570f9de3/src/debug.ts
Nice idea. But those preload skripts are actual skripts loaded in the actual debugger aren't they?
While that would be useful to have automated I can (and actually do) this already with source myscript.py in the launch configuration on autorun.
What is "missing" is to change the commands, for example instead of -data-evaluate $var I'd call myprint-command $var and parse the async return different later. Similar to breakpoints, those would be altered by gdb "console" commands that are part of the sourced myscript.py.
A plugin API sounds nice, if you see that coming and/or would like to work on it (I'd provide the API user part ;-) then that would be cool; but I guess the more easy option is to fork and then do those changes directly (I'd like to pass the language identifier from the frontend to the backend, maybe that could be done in this repo, too).