Define IIdentifiedSingleEditOperation.range as IRange instead of Range

[bolinfest]

With the upcoming changes in TypeScript 3.8 to support import type, it is even more compelling to declare weak references via types rather than strong references via concrete classes. Most APIs in Monaco already do this well, accepting monaco.IRange instead of monaco.Range, though IIdentifiedSingleEditOperation appears to be an exception in this regard, which means a strong dependency on monaco.Range is required to use ITextModel.pushEditOperations().

It would be nice to relax this constraint, though I admit I have not yet attempted to trace through whether this breaks anything since I am submitting this via GitHub's web UI.

This PR fixes #

[bolinfest]

Indeed, the test failures illustrate where VS Code/Monaco expect a Range rather than an IRange. For example, snippetSession.ts has this line:

return undoEdits.map(edit => Selection.fromPositions(edit.range.getEndPosition()));

Would you be open to changes like Range having a static getEndIPosition() method so that edit.range could be an IRange? Presumably it could be implemented as follows if the existing getEndPosition() method were special in some way:

function getEndIPosition(range: IRange): IPosition {
  if (range instanceof Range) {
    return range.getEndPosition();
  } else {
    return {
      lineNumber: range. endLineNumber,
      column: range. endColumn,
    };
  }
}

I'm happy to go through and try to do these sorts of refactorings, but if you aren't open to this change, then feel free to close the PR.

[alexdima]

Thank you!

[bolinfest]

w00t!!! Thanks @alexdima for taking my proposal and making it legit!

[bolinfest]

@alexdima Did you intend for this to be a Range rather than an IRange? Without tracing through the code, I assume it's extra work to relax this constraint right now?

[alexdima]

That is intentional. You can see how IValidEditOperation is always returned from the editor or passed in as a callback argument by the editor, so this is not a constrained on the editor user, it is a constrained on the editor implementation.

[bolinfest]

Also, @alexdima I'm not sure how much work it is on your end to publish a new monaco-editor release, but I would love to take advantage of this fix if it isn't too much work. Maybe I can try to land some other perf fixes to Monaco to make a new release more worth your while...

In the meantime, I'll guess I'll try following the instructions on https://github.com/microsoft/monaco-editor/blob/master/CONTRIBUTING.md to produce a local build.