Because one of the goals of RemedyBG is to use an existing text editor, parts of the debugger user interface are built on top of that editor by you. Editor-specific functionality includes rendering an indicator at the current line of code as the user is stepping through a target and marking where breakpoints are set. My editor of choice is Vim and as such there will be support for this editor included as part of this project.
RemedyBG does provide the ability to create and control one or more inspect window UI elements which can display callstacks, registers, threads, program state, and much more. The inspect windows are implemented using a unified model of navigation through structures proposed by Casey Muratori. This opens the door to a ton of really neat features. For instance, an inspect window can be setup to display an array of structures with the fields of the structure set up as columns in the list view (a very handy feature).
Splitting up the responsibilities like this allows you quickly create a powerful debugger in the text editor of your choice whether that happens to be Vim, Emacs, 4coder, Sublime, or any other customizable editor.
And oh yeah, this debugger doesn't use any third-party libraries. None. This includes Window's own Debug Help Library (DbgHelp), Debugger Engine (DbgEng), or even a library for reading symbol files (PDBs). I played around with these libraries to judge their effectiveness. Yes, using them can get you 80% of the functionality you need but after that you are forever 20% away from sweetness. And besides, Visual Studio is using these libraries and the whole point was to get away from this beast! All the code for RemedyBG is written from scratch which allows for a great deal of flexibility with respect to the functionality that can be implemented.