Author Topic: Navigation practices for references  (Read 20236 times)

hutnut

  • Community Member
  • Posts: 9
  • Hero Points: 0
Navigation practices for references
« on: February 26, 2009, 09:05:26 pm »
As a long time SlickEdit user, I still find it awkward to navigate references. I routinely find myself in situations where I need to walk the call tree for some function. I right click the function and select 'go to reference'. That's great. But now I need to know what function called this function and so on and so on up (or down) the call tree. It appears the reference window is always only one level deep and in a big project, I quickly become lost as to where I'm at. Am I missing some navigation features or different operation tips? A few collegues use SourceInsight which manages this reference call tree as N levels deep. Any help would be appreciated. Tx.

donjoe

  • Community Member
  • Posts: 35
  • Hero Points: 1
Re: Navigation practices for references
« Reply #1 on: March 23, 2009, 02:25:18 pm »
Seconded.

I too have, on occasion, found myself wishing there were a way too see a complete tree of function calls starting at a specified function in the current project. This would be a huge help in understanding (poorly-documented) complete projects I'm inheriting from others.

Please give SlickEdit this super-power. :P

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4938
  • Hero Points: 404
Re: Navigation practices for references
« Reply #2 on: March 23, 2009, 03:52:21 pm »
SlickEdit's Call tree feature does support starting from a symbol and nesting in. Click the Expand button to expand the tree items immediately or just expand the tree items as you need them.

This feature seems too hard to get to. Right now, the easiest way to get to this feature is to right click on the symbol in the edit window, choose "Show in symbol browser", then right click again and choose "Calls and uses".  It seems to me there needs to a "Call tree" or Calls and uses menu item for the edit window context menu.  Would this help?

donjoe

  • Community Member
  • Posts: 35
  • Hero Points: 1
Re: Navigation practices for references
« Reply #3 on: March 24, 2009, 05:49:26 pm »
SlickEdit's Call tree feature does support starting from a symbol and nesting in.
[...]
Right now, the easiest way to get to this feature is to right click on the symbol in the edit window, choose "Show in symbol browser", then right click again and choose "Calls and uses".
Cool! Thanks for the tip! (It would be nice if I could get rid of all the non-function items in that view, but hey, it's still much better than nothing.)

Quote
It seems to me there needs to a "Call tree" or Calls and uses menu item for the edit window context menu.  Would this help?
Absolutely. I'd put it right there under "Go to References". :) But is there a direct command for it? I couldn't find one.
« Last Edit: March 24, 2009, 05:51:12 pm by donjoe »

Tim Kemp

  • Senior Community Member
  • Posts: 536
  • Hero Points: 90
Re: Navigation practices for references
« Reply #4 on: March 24, 2009, 06:59:41 pm »
The call tree is really nice, but I think what the original poster was looking for was a way to navigate the other way.  Often when I'm looking at unfamiliar code I'm trying to figure out how I may have gotten to a particular spot, so I'm navigating upstream.  I repeatedly use "Go To References", not "Go to Definition"; although that's obviously important too.  Personally I have buttons on my mouse dedicated to "Go To References", "Go to Definition" and "Pop Bookmark".  I find I can navigate very quickly through code that way, but if there was some way to navigate to resources through a graphical tree it would be even better.

donjoe

  • Community Member
  • Posts: 35
  • Hero Points: 1
Re: Navigation practices for references
« Reply #5 on: March 24, 2009, 07:20:17 pm »
It would be nice if I could get rid of all the non-function items in that view
Hah, and I can: right-click in the Calling Tree window, select "Quick filter" > "Functions only". :D

Quote from: Tim Kemp
I think what the original poster was looking for was a way to navigate the other way.  Often when I'm looking at unfamiliar code I'm trying to figure out how I may have gotten to a particular spot, so I'm navigating upstream.
Ah, so you'd like to generate a tree view starting at the current function and branching out to the left or upward, to include all the possible callers of the current function (and their callers etc. all the way to main() or whatever).

Tim Kemp

  • Senior Community Member
  • Posts: 536
  • Hero Points: 90
Re: Navigation practices for references
« Reply #6 on: March 24, 2009, 07:40:46 pm »
Yes, something like that.

Possibly there could be a view where the current object is in the middle and all the references to the object are to the left and all of the "uses" are to the right.  For my purposes just having one level on each side would be fine.  It would also be nice if you could keep track of how you got there by highlighting the one on the left and/or right that got you there; sort of like a web browser showing followed links in a different color.  The ability to navigate back and forth through the chain you've been following and set bookmarks from the navigation-tree view, would be nice too.

donjoe

  • Community Member
  • Posts: 35
  • Hero Points: 1
Re: Navigation practices for references
« Reply #7 on: March 25, 2009, 06:53:02 am »
For now the closest thing seems to be if you just open the (complete) Calling Tree for main() and always navigate from there (a double-click on any function name in the tree opens and centers the appropriate source file). And the track you followed to get to a certain function will be visible because all the other branches will be collapsed and only the one you followed will be expanded.

Tim Kemp

  • Senior Community Member
  • Posts: 536
  • Hero Points: 90
Re: Navigation practices for references
« Reply #8 on: March 25, 2009, 12:54:55 pm »
Quote
For now the closest thing seems to be if you just open the (complete) Calling Tree for main() and always navigate from there

That will work fine for small applications.  However, on large applications where you have no idea what relationship main() has with the code you are trying to find, or lower level code where execution doesn't start with main() it's not very practical.

The project I'm working on now has nearly 5000 C++ files with around 1.5 million lines of sparsely commented code.  I've been involved with the project for a couple months now, but I'm only really familiar with a few isolated sections.  I jump back and forth with the "Go to Reference"/"Go to Definition"/"Find in Files" functions constantly while adding code annotations to try to get an understanding of it.  Those functions are wonderful and I would be lost without them, but if there were a more automated way to navigate unfamiliar code I'd certainly appreciate it.

buggyfunbunny

  • Senior Community Member
  • Posts: 233
  • Hero Points: 4
Re: Navigation practices for references
« Reply #9 on: March 25, 2009, 01:08:43 pm »
<rant>
Ever since discovering the writings of Allen Holub more than a decade ago, I understood what made me itchy about how OO coding as it actually gets done; at least in the java (and I suspect C++) world.  It's procedural structures with data classes and action classes (often with Data and Action in the class names, just to let us know).  The java frameworks, with the Bean Paradigm, are the worst offenders.  The only solution, and it has always irritated me that it *is* the only solution, is programming from the debugger.  It's one of those vicious circles; bean paradigm programming begets the requirement for debugger tightly coupled to the editor, which begat Visual Age for java, which begat Eclipse, which sends those of us who can to Python, Ruby, and the like.
</rant>

Tim Kemp

  • Senior Community Member
  • Posts: 536
  • Hero Points: 90
Re: Navigation practices for references
« Reply #10 on: March 25, 2009, 01:21:48 pm »
Nice rant.  I started programming in the late 70s and programmed largely in C and various assembly languages into the 90s.  We didn't need no stinking OO (to be fair we didn't have it either  ;).)  I've worked on horrid procedural code and OO code, but personally I often find bad procedural code easier to work on than reasonably good OO code.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4938
  • Hero Points: 404
Re: Navigation practices for references
« Reply #11 on: March 25, 2009, 08:41:40 pm »
For the record, there isn't a command which brings up the call tree for the symbol at the cursor.  Like I said before, we really need this on the context menu.

Tim Kemp

  • Senior Community Member
  • Posts: 536
  • Hero Points: 90
Re: Navigation practices for references
« Reply #12 on: March 25, 2009, 09:04:19 pm »
Clark,

You are right, it would be nice to be able to pop-up the call tree from the context menu.  However, as far as I can tell there isn't any pretty way to go the other way and walk the reference tree.

- Tim

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4938
  • Hero Points: 404
Re: Navigation practices for references
« Reply #13 on: March 25, 2009, 09:13:53 pm »
No way to do it yet.  It's a very doable feature especially if it do it incrementally i.e go back one level at a time to see what calls the symbol you are on.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2822
  • Hero Points: 426
Re: Navigation practices for references
« Reply #14 on: March 26, 2009, 03:21:00 pm »
This command will get you halfway there to the call tree, provided the symbol under the cursor is in a tag file, and not a local or in a file which is not tagged.

Code: [Select]
_command cb_show_calltree() name_info(TAG_ARG','VSARG2_EDITORCTL|VSARG2_REQUIRES_MDI)
{
     cb_find();
     cb_calltree();
}

With respect to stacking references, we have had a long standing feature request to make this tool window be able to managed a stack of references, similar to how the Search results can manage different sets of search results.  The tricky part is knowning when to pull a reference list off of the stack.

I have often thought that references and search results should be the same, but as you can tell they are currently very different looking -- references being focused on showing you the symbol context and search results showing actual text like 'grep' results.