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. Pros: You have all the info. Cons: 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 Pros: Transparently works in the simple case of one split Doesn't break code Cons: 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: Pros: Works with old code, regardless of which split you look at Cons: 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 d) ? S. |