Comment 1 Stephan Herrmann 2016-09-12 16:09:07 EDT

Given the tree structure of this view, I'm not sure we can easily agree on an intuitive traversal strategy that fits the notion of "Next".
Do you care to elaborate what exactly you had in mind?

Comment 2 Lars Vogel 2016-09-12 16:22:04 EDT

(In reply to Stephan Herrmann from comment #1)
> Do you care to elaborate what exactly you had in mind?

Next/ previous direct caller of the root "search" element

Comment 3 Stephan Herrmann 2016-09-12 16:33:52 EDT

(In reply to Lars Vogel from comment #2)
> (In reply to Stephan Herrmann from comment #1)
> > Do you care to elaborate what exactly you had in mind?
> 
> Next/ previous direct caller of the root "search" element

And once you selected a (deeply) nested child node, rather then a direct caller, this operation would be a NOP?

Comment 4 Lars Vogel 2016-09-12 16:54:30 EDT

(In reply to Stephan Herrmann from comment #3)
> And once you selected a (deeply) nested child node, rather then a direct
> caller, this operation would be a NOP?

I think it should continue to select the next / previous direct caller.

Comment 5 Stephan Herrmann 2016-09-12 17:16:09 EDT

(In reply to Lars Vogel from comment #4)
> (In reply to Stephan Herrmann from comment #3)
> > And once you selected a (deeply) nested child node, rather then a direct
> > caller, this operation would be a NOP?
> 
> I think it should continue to select the next / previous direct caller.

m()
 - m1()
   - m11()
   - m12()
     - m121()
     - m122()
     - m123()
   - m13()
  -m2()

"Next" on m122() would then jump to m2(). No way! :)

Comment 6 Markus Keller 2016-09-14 12:15:12 EDT

I agree the Next/Previous buttons/shortcuts from the Search view would also be nice in the Call Hierarchy. They should behave the same as in the Search view where this makes sense (e.g. keep the focus in the view after jumping to the next occurrence).

The Call Hierarchy differs from other views in that the expansion state has much more relevance than elsewhere, so automatically expanding nodes like in the Search view would not be a good idea.

I think the the Up/Down arrow keys already provide most of this, including a useful traversal order. The only missing part is that the Next/Previous actions should additionally traverse through the second, third, etc. match in case there are multiple matches per tree item.

Comment 7 Stephan Herrmann 2016-09-14 14:11:11 EDT

(In reply to Markus Keller from comment #6)
> [...] The only missing part is that the Next/Previous
> actions should additionally traverse through the second, third, etc. match
> in case there are multiple matches per tree item.

That would indeed add significant value. I like that.