We also encountered a similar problem, see your explanation The reason why Editor replaces all behavior characters with \n is for internal performance optimization.
But the last mentioned conversion of a position by an offset will be a huge performance penalty for large text documents.
Part of our feature is full C# code editing support，and we use a third-party analysis engine for syntax analysis.Some interfaces in the .NET parser (Roslyn) use offsets as parameters, but some also use positions.
So inevitably need to call the conversion method on the Editor, but the current situation makes it difficult for us to accept. Dealing with line endings should be the responsibility of the Editor, but we need to do additional processing, and the most important thing is the performance loss caused by the offset to the position.
For the user, I should only care about loading, saving, and manipulating the document.However, because SyntaxEditor does not handle the difference of line endings, the data obtained directly through the calling interface may be inconsistent with the real data, and it needs to be processed again by the decorator.
This is so unreasonable!