Thanks for the offer! Right now it can run with or without 4coder, but without 4coder, there isn't any interface to the source code.
I have actually been struggling to figure out the best way to proceed. These are my scatterbrained thoughts:
So I was thinking of providing multiple editor interface modules, and I feel like I have a good handle on how to do an Emacs and a 4coder interface. With that and also I had someone graciously offer to test who is on emacs I was thinking I could, for the time being, directly provide/support modules for those editors. However the more I thought about it, I could spend a lot of time working on those while the debugger at its core is still missing basic features.
I was also thinking that I could just make an API that handles the editor interfacing, and then have the user compile and link in their implementations, much like the 4coder super customization layer. I feel like this might be the best route to support editors like Glyphin and Vim, both of which might benefit from someone who is more familiar with those editors to write the interfacing implementation.... However, I think it's way to early to get into designing what the API should be for that.
Im now thinking that it would be best to take a step backwards from editor integration altogether. I skipped over any source browsing functionality in the debugger because I wanted first-class support for editor interaction as one of the primary features of the debugger, however that seems more and more premature, so I'm thinking it would be best to just go ahead and implement a basic read-only source code browser in the debugger, and that would simplify some things while I just focus on debugger core features
Of-course I could stick with the original plan and just support 4coder...
Anyway I'd be interested in any feedback, suggestions, comments, concerns or insults :)