SF2 Debugger useability

David,

I'll try to answer each issue you've listed:

(1)  This statement is true.  When the executable terminates, it doesn't turn off the debugger.  This behavior was originally because the program might terminate abnormally, giving you the chance to examine what happened.  It also allows the user to click "Restart" in a sensible manner.  I'd like to leave this behavior in for those two reasons, but perhaps an additional debugger state, "Off," is necessary to clear up what's happening.

(2)  Leaving the console open might be tricky.  That window is opened by GNU Debugger, not Simply Fortran.  I'll see what I can do.  Using the tab panel has proven to be problematic with the debugger because we're working on Windows.  Basically, all debugger interaction with Simply Fortran is handled through standard input/output streams.  Simply Fortran is smart enough to know when the output from the child process isn't a GDB message, displaying it as program output.  However, things get tricky with text input.  A more elaborate system is necessary to put the debugger back in a tab.  I am working on it, though.

(3)  Simply Fortran's indexing and syntax engines will always update whenever a tab is switched.  The indexing is a pretty lightweight, fast process, so I wouldn't worry so much about it.  It is, however, aggressive, and runs whenever tabs are switched.  The syntax engine in contrast is CPU intensive since it is launching the compiler each time.  You can disable this during debugging from the Options menu.  In fact, I would recommend it on single-core systems.

(4) I'm not sure disabling editing during debugging is the best plan.  I understand your use case, but there is something to be said for being able to quickly make a fix as the debugger proceeds, even if you're not going to see the results until a re-compile.  A reasonable number of users complained about Insight's inability to edit when a small typo or bug was encountered, so you'd be limiting options.  Feel free to convince me otherwise, though.  I'm open to ideas.

(5) Simply Fortran's panel management is simple to the point of madness.  Any new tabs will be opened beside the currently selected tab.  So after you move your build and console tabs to the bottom, one of those is the current tab, and future files will open next to them.  Unlike other IDEs, Simply Fortran considers the build and console tabs to be peers with editor tabs, not some other type of tab that can't live amongst the editor tabs.  Fixing this gets back to demands for remembering open tabs, etc. that users have requested.  The 2.x series will at some point implement saved tab positions.  Along with it, some special handling of build and console tabs may fix the behavior you're discussing.

(6) Showing the debugging panel automatically makes sense.  I'll add that.

(7) The extra step has just been added.  Very good point.

(8 and 9) Version 2.0 was to only support the simplest of breakpoints.  It just doesn't have watchpoints and conditional breakpoints yet.  They'll be coming, of course.

(10) "Run to Cursor" will be added as well.

(11) I understand you really want that console.  I'd like to hear from other users as well.  For inspecting global variables, I've relied on Watches myself.  However, everyone's workflow is different.  I'll look into a nice interface for it.

I hope I've addressed your suggestions to your liking. This being the first version integrating the debugger, I expected a long list of bug reports/complaints/suggestions to flow into the forums.  I must say that things have gone better than I originally expected.

Simply Fortran has a long history of rapid updates (46 releases of the 1.x series in about 3 years), so many of your desired features should appear soon.  I really appreciate all the feedback from both yourself and all our users!

(4) Disabling editing during debugging.

I prefer to leave the code editable during debugging.  Perhaps post a warning flag somewhere to remind users that code being debugged is not an up-to-date compiled executable of teh latest version, as soon as the code is touched.

What I WOULD like to see is automatically exiting the debugger as soon as a user clicks the re-compile icon, instead of the compiled code failing to link/load when it finds the executable is still open in the debugger.

(11) Console

I'm very interested to read this.  I printed and wire-bound a copy of the GDB manual, and found it about as readable as Klingon.  And WHAT a monster manual, too!  Result - I use it as an end-stop on a bookshelf.  Can one of you list a few siomple examples of useful commands producing immediately useful outcome, which one can type into the console?  This would a be a great way for amateurs like me to get started.
---
John

Version 2.2 has the button on the toolbar as requested.