Today Razor's range/edit remapping is entirely based on "mappable" ranges. Meaning, if we get an edit to the backing C# file we can only lift it to the top-level buffer IF we have mappings associated. However, we can be better.

What IF we were to have more knowledge on where the edit was happening in the C# document and what was impacted for unmappable edits. For instance lets take thee scenarios:

Scenario 1 - C# using directives (✅ Done )

When a user invokes an "Add using" light bulb it adds the C# using directive to an unmappable location in the generated document. To understand this we can diff the using syntax nodes of the C# document before/after to see what has changed to properly translate any added using statements

Scenario 2 - Extract to local

Today extract to local isn't actually supported and the reason why is that in C# when we do "Extract to local" the generated C# that's created exists outside of the #line pragma's that the Razor compiler generartes. To address this we could detect that an edit was happening in the "Render" method of the Razor file (we'd special case it) at which point we could then follow a decision tree:

• Is there a pre-existing @{...} around the origin edit location?
  • Yes: Add the edit content to it
  • No: Create a new one and insert the edited content

Scenario 3 - Generate method

Today generate method isn't supported because when generating a C# method it adds a brand new C# component to the backing C# file in an unmapped location. To address this we could detect that the edit was happening in the C# class body of the generated C# of the Razor file and then follow a decision tree:

• Is there an existing @code or @functions (C# directive block) block?
  • Yes: Find the closes "mapped" code to the backing C# edit location and then insert the new edit contents into the C# directive block
  • No: Create a new one and insert the edited content