learning from debuggers and word processors

Continuing on the subject of a code editor.  I'm calling it "ned," for Nate Edit.  What?

When debugging code in a modern debugger, there's a window called a watch window that shows you the state of various relevant variables.  You can use this to visually inspect the state of the program as it runs.  Is there a place in the Ned UI for a similar collection of symbols?  In many editors this information is exposed through autocomplete, and I think that's a good feature, but is it quitting early?

• Maybe things that are in tooltips or autocomplete windows now, should have permanent real-estate in ned.
  

On the topic of debuggers, and what we can learn from them: many editors, notably eclipse (which I hate for unrelated reasons), continually compile your code as you work, so that it's ready to run at a moment's notice, and so that errors are highlighted on the fly.  Is this quitting early?  

• Maybe instead of just constantly compiling the code, we should be constantly executing it in a sandbox, and putting breakpoints at the cursor so that you can see the state of execution as you code.*
  

I don't like managing white space, brackets, and navigation; I hate getting lost in a project.  The editor should do as much of this as possible by itself.  Many editors have automatic beautification, white-space removal, and browser controls, but the programmer is still in charge of managing the tags, the text, the markup.  This is quitting early.

• Maybe we can apply some of the lessons of WYSIWYG html editors to writing code; the markup that creates the logical structure is not important; visualising the logical structure is.
  

*OK so, this sounds totally implausible at first, but hear me out... what if when the program is executed in the debugger, we capture and remember the most recent program state and parameters that were passed in to each function.  Then, when I'm coding that function, we automatically compile and run just that function, in the context of the saved state.  It might not always work, but I think most of the time it would give you more insight into what's going on as you work on the code.