Feature: better highlight moving with multi-select #50
Description
This is a very low priority feature I considered when working on the multi-select upgrade. After adding a template or node to a tree without anything selected, the highlight "jumps" to the first important location, or where the app suspects the user to want to update next.
With multi-select, I didn't make the highlight move at all if this operation works on multiple nodes at once. The original reasoning was that if you add so many nodes, there would be some ambiguity as to where the next logical place to edit would be. I figured it was easier to just leave the highlight where it was and let the user move exactly where they want instead.
I then went through a change of heart and decided that maybe I'll just add a default move anyway, figuring if the user needed to move, they would have done so anyway, but if they had wanted to go where the highlight predicted, I would have saved them a key press or two.
But then I got lazy and never got around to adding this feature. And since then, I've been really torn over which conclusion I end up liking more, so I'm really not sure if this is a feature I want to spend time implementing since I really don't feel like it's all too necessary.
Anyway, the result is this issue: a very, very low priority thing that I have no interest in focusing on until after release.