Terminal editor should prefer to open files in a different group

[sbatten]

Testing #131196

Sorry if this has already been discussed at length in the recent UX call and I know this is as-designed behaviour. However, the steps I follow here lead me to unexpected behaviour:

1. Set the experimental locked group setting to always open terminal editors locked.
2. Open a new terminal editor as the only open editor in the only opened group
3. In the opened terminal, code-insiders file.txt

This opens the file over the terminal. The most intuitive behaviour here for me would be to open all files to the right of the terminal. I have told you I want terminals to be locked with settings so I find it strange that I have manually create the second group before operating with it.

Feel free to close if this thought has already been considered.

[bpasero]

Yes, we did have long discussions around this but only in a smaller group. Our main intent is to reduce friction so that when you go back to 1 group, you don't have to deal with locked groups anymore.

However, this particular scenario I think we can improve: if the result of opening an editor originates from within a terminal editor, I would argue it should signal to the editor service to open in a different group and not the same group.

I had this idea before: what if we had a OTHER_GROUP constant that you can use in openEditor similar to SIDE_GROUP which would act exactly as if the current group was locked. It would serve as a hint that the editor should open in any of the other groups or open a new group if that is not possible.

Would like to hear from terminal folks if that is reasonable and then I could add such a property.

[Tyriar]

I think the current behavior of opening the file over the terminal seems fine, adding another special case to the existing special case of single editor groups seems a little convoluted. Locked groups to me are only useful/enabled when there are 2+ editor groups.

[sbatten]

I think the current behavior of opening the file over the terminal seems fine, adding another special case to the existing special case of single editor groups seems a little convoluted. Locked groups to me are only useful/enabled when there are 2+ editor groups.

I don't know if I agree here. I think the setting is the useful part about locked groups, otherwise it's a lot of manual management. However, waiting to get user feedback makes sense.