XCode: Better symbol navigator for current class

Question

Is there a plugin or some other way for XCode 5 to make the symbol navigator more useful, by only showing the current class and making the #pragma marks appear as if we click on the jump bar?

The point of all this would be that we do not have to click the jump bar, the navigator is always displayed as a tab on the right panel.

The default symbol navigator on the left panel is weak in my opinion.

See attached image.

EDIT: I ended up creating the plugin myself. You can download it at: https://github.com/zolomatok/ZMDocItemInspector

If you are interested in writing your own plugins, here's a detailed tutorial helping you out: https://github.com/zolomatok/Creating-an-Xcode-plugin

Answer 1

Not that I know of, but a few techniques that might make your life easier:

1. Press control+6 to bring up that document items pop up (that list of method names and pragma marks) quickly.

2. By the way, when that's up, many people don't know that you can just start typing and it will also do a search in that pop up, pruning out items that don't match what you typed.

3. You might want to consider using the symbol navigator, which you can pull up by pressing command+2 or by tapping the second tab in the navigation panel:

   

4. Another great tool is Quick Open (shift+command+O (that's the letter "oh")).

5. Code folding is also a way to quickly collapse your code so you can quickly navigate to a particular routine. You can press shift+option+command+left arrow to quickly fold all of your code, scroll to what you need, and then unfold (either all or just that routine).

6. A little more complicated, but you can employ a documentation system. I use appledoc. You can put comments in your code that conform to HeaderDoc or Doxygen formats. So consider the following method declaration:

   /** Initialize `Download` operation, downloading from `url`, saving the file to `path`.
    *
    * The operation starts when this operation is added to an operation queue.
    *
    * @param url The remote URL of the file being downloaded.
    *
    * @param path The local filename of the file being downloaded. This should be the full path of the file (both the path and filename) and should be in a directory that the user has permission.
    *
    * If this `nil`, the filename will be taken from the `lastPathComponent` of the URL, and will be stored in the `Documents` folder.
    *
    * @return Download operation
    *
    * @see initWithURL:
    */
   
   - (id)initWithURL:(NSURL *)url path:(NSString *)path;
   

   The structure of this comment is (a) start with /**, not just /*; and (b) specify @param and @return descriptions. When you do this, you can feed your code into one of these documentation engines, and you'll get a nice set of documentation. This includes a class hierarchy, too.

   But, while we all know we should document our code, but in Xcode 5, we have a more compelling reason to do so, as our comments are automatically integrated into Xcode's native help system, realtime. By inserting these comments in your code, Xcode 5 now automatically shows you the documentation for your methods in the Quick Help window, just like it does for the Cocoa classes.

   In answer to your question of being able to see the whole class hierarchy, using appledoc you can build and install a "docset" that you can show in Xcode's documentation browser (in the Organizer in Xcode 4.x, in the separate Documentation window in Xcode 5) by navigating to your project's folder running the following command in the Terminal command line:

   appledoc --project-name MyApp --install-docset --output ../MyAppDocumentation .

   In addition to building a docset that you can view in Xcode, these documentation systems let you build documentation that you might share with third parties (if you ever need to do that). Appledoc in particular generates a very Apple-like HTML documentation site. For example, here's the documentation for the above method declaration.

   This separate "build a docset from command line" isn't as slick as an "add in" that you're envisaging, but I find that with Xcode 5's built-in parsing of documentation, I've personally integrated the documenting of my code in my development process. (I'm embarrassed to say that it used to be one of those things that I deferred to the end of the development process.)

For more techniques to streamline your interaction with Xcode, see WWDC 2012 video Working Efficiently with Xcode or WWDC 2013 video Xcode Core Concepts.