Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Document:getText fixes #4366
Purpose and Motivation
The asynchronous version was introduced in 977bd3a on July 18, 2013 (tagged Version-3.7.0-alpha0).
The synchronous version replacing it (578ab14) dates to August 8, 2013, also tagged Version-3.7.0-alpha0.
So the asynchronous version existed for only about three weeks and was superseded before its alpha release. It's a safe bet, then, that no user code relies on the asynchronous version.
And, the synchronous version wasn't usable (edit). So it's a safe bet that no user code is relying on the current, synchronous version.
So I think my approach here is reasonable -- clean up
Which leaves the question, why do we need
I would suggest, until we are 100% sure that document text mirroring is reliable on all platforms, that we should keep the asynchronous approach around as a backup. User impact in my case is that I was accessing document contents in order to save them as part of a JIT patch (see https://github.com/jamshark70/JITModular/tree/topic/patch). In Windows,
Types of changes
Apologies James, this was all done a rather long time ago and my memory is hazy. My rough recollection is that:
Going forward, I would suggest adding the start and range args to
As to the async approach, I'm not sure what to suggest. There are definitely some issues, and it may be that it would have been better to go with the async in any case, but there's a fair amount of code that depends on sync. Having an async option doesn't hurt I suppose.
Thanks for the background. It looks like the interface needs a general review. I see:
That's a lot of duplication. I totally missed
Also consider compatibility with TextView, which has
From that perspective, it might be best to dump (deprecate) all of the
Async: Synchronous string-getters are, of course, better -- provided that they work. In 2013, it seemed to be working on Mac and Linux (I haven't seen any problems with it in Linux), and not extensively tested in Windows, so there was no apparent reason not to go forward with that. Just recently I find that I can break it often in Windows (though not on demand). I have a feeling it's going to be difficult to find the cause -- so we should have a way to query the real owner of the text.
Ironically, it's lucky for me that the feature was not finished. If it had been, somebody might have said "OK, now we can remove the text-access handlers from the IDE backend" (before the feature was thoroughly tested) and then I would have no alternate approach today.