On 19 Nov 2013, at 01:40, James Harkins <jamshark70@xxxxxxxxx> wrote:
I'm wondering if any temporary measures might help? If you're calling methods on Document.current or any document with no splits, then it's easy, right?
Well, nothing is 'easy' ;-). Since getting selections should be synchronous, and there's fear about touching the interpreter too often, it will probably have to be stored in a back end lang mirror, like doc text now is. That's not a huge deal, but I'd rather not spend time on something temporary (and nobody else has volunteered ;-).
In some ways, I think the old model is wrong with the IDE: Probably there should be a DocumentView class or something like that. But that would break code, which we've so far managed to minimise, and seems like a lot of work and complexity added for something that might only rarely be used. So we could:
a) Selection gets or sets Arrays of selections.
You have all the info.
How do you determine order?
Breaks code unless single selections don't come in an Array, but then you need to check, or code breaks when user opens a split.
Does anybody really need this?
b) Selection gets or sets the last active split
Transparently works in the simple case of one split
Doesn't break code
Could be confusing in cases were the doc you are setting has splits and is not visible
c) Selection gets last active split and sets all splits:
Works with old code, regardless of which split you look at
get one, set all inconsistent
Possibly a hostage to fortune if some use case arises in which you need to deal with multiple splits/selections