[limmeau]

I can really recommend debugging with command-line gdb (inside a text editor, of course; we're not barbarians). The transcript that lets you look back at the past of your debug session really adds a new dimension to the debug experience that a plain IDE integration just does not offer.

(Time-travelling debuggers are OK, too, I guess)

[azeirah]

What do you mean by transcript? I used gdb a while ago and it's mostly similar to a regular terminal application with readline.

[limmeau]

By transcript, I mean every command and every response in the debug session. Usually, in the beginning, I do not know yet what I'm looking for, and set breakpoints at points that may be interesting, and when I reach the breakpoints, I look at variables. Later, when I reach the point where things have gone wrong, I can look at variable values now, but also at the result of every previous query. This helps me answer questions like: was this object here already in that queue over there when the previous request came in?

I can also attach the debug session to an issue in order for others or future me to understand what was happening then. In a purely GUI-driven debugger, I can copy&paste a stack trace of the final point, but the history is lost.

[loeg]

I've used scripts + logging in the past:

https://sourceware.org/gdb/onlinedocs/gdb/Logging-Output.htm...

Maybe that is what OP means by a transcript.

[pjmlp]

Just like I was doing with XEmacs in 1995...

There is so much a modern IDE debugging session is capable of.

[elteto]

What do you mean “inside a text editor”? What’s the workflow that you describe like?

[mikepurvis]

I think it just means inside your editor's terminal, where there's usually some modest integrations like it detecting a source/line reference and either jumping you there or at least making it clickable.

VSCode for sure does this.

[adhesive_wombat]

I cannot for the life of me get gdb to debug a remote in VS Code. The debugger runs, and breakpoints work and integrate, but the console is dead. '-exec print foo' does nothing.

[donio]

GUD in Emacs (M-x gdb) is another example of this. You are still interacting with the gdb cli but also get some source code buffer integration.

[limmeau]

gud-gdb in Emacs, yes.

[pjmlp]

Time travel to the UNIX world of early X Windows days.

Now picture XEmacs and Emacs, running gdb as subprocess, with a little pointed finger showing the current line and a stop sign for breakpoints.

The lower buffer shows the usual gdb repl and output.

[gumby]

Time travel to the late 70s and use the lisp machine debugger.

I always felt the drive towards mouse-driven tools in the PARC world (InterLisp/SmallTalk/CedarMesa) was actually a regression because of the loss of history ("how the hell did I get here?")

[pjmlp]

They also had a proper REPL, and the reason I stay with Java and .NET ecosystems, is because they are the closest we can get back to the Xerox experience, after the UNIX divergence.

[stjohnswarts]

Still available with DDD and various plugins to vim/emacs/vscode