For instance, if I have a file that compiles and I start typing in the space between two function bodies, I'm probably implementing a new function. In fact that probability is so high that you should just assume that to be the case, even if the code I've written so far doesn't have balanced nesting yet. All decisions and advice should be based on the speculation that the code will eventually represent a new set of blocks, not a reorganization of the remaining ones.

You can't make the same assumption about if statements inside of a function, or about incomplete multiline comments, but you can assume that anywhere from zero to all of the sibling blocks are about to have their scope changed (but not ancestors).

In short, the gap between how I'd describe a commit and how the diff tool represents it also prevents live code analysis from being able to work as well as it might.

    fn foo() { }

    fn

    fn bar() { }

    SOURCE_FILE@[0; 31)
      FN_DEF@[0; 12)
        FN_KW@[0; 2)
        NAME@[3; 6)
          IDENT@[3; 6) "foo"
        ...
      FN_DEF@[14; 16)
        FN_KW@[14; 16)
        err: `expected a name`
      FN_DEF@[18; 30)
        FN_KW@[18; 20)
        NAME@[21; 24)
          IDENT@[21; 24) "bar"
        ...

Sounds like we lost some of that along the way.

Most programming languages aren't designed for parsing backwards, though!

(Aside: are you from n-gate.com, as your username suggests?)