Simon Sobisch

Your output says: > ```shell > Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333" > ``` That's likely a good idea, see https://github.com/WebFreak001/code-debug/issues/330 for the...

> Someone above mentioned something about a timeout or delay... this smells a lot like a timing issue to me. Hm, then I suggest to post the log with `"showDevDebugOutput":...

Actually there are two options depending on the support the debug extension claims. If it claims it supports a restart then an appropriate command is executed, if it doesn't then...

The referenced issue was about setting breakpoints at all, especially on connect, which was solved by adjusting the order of the connection and the optional, configurable "break at start". In...

Yes, that's supported, see #330 for the issue that currently documents how this is done (feel free to send a PR to add this to the README) and about how...

Are those commands actually lagging? The commands themselves get in later. It _looks_ like the right option is to keep a "is running" state variable (if we don't have it...

The first part was done in #354 by @brownts. 👍.

Thank you this sounds very usefull. The next thing would be to increase the test coverage...

The idea was to start the xterm and use the existing port forwarding; pass its pty to GDB via `-tty`, then let GDB start. In this case the application would...

Hm, I'll hopefully will try to find some time using a plain ssh session, then report back.