Those red thingies with the X in them

Sometimes the hardest part about finding the solution to a problem is finding the right terminology with which to characterize the problem.

I have been using SlickEdit 2009’s Build command to build my C++ project.  The major reasons I commonly kick off the build from within the IDE (as opposed to from the command line) are:

• I can double-click on an error and jump to it; and
• Little red thingies with an X in them appear along the left side of the editor window, providing a quick visual of where the errors are on the current screen:
  
  (It would be even nicer if there I could also get a view of where all the errors are in the current file, like Eclipse (or was it WinMerge?) provides.)  I can hover over one of the red thingies to see all the errors for that line.

Today, the red thingies weren’t there.  I could still build; I could still double-click on errors in the captured build output in the Build window; but I had to actually read things because the helpful visual wasn’t there.

Error Markers

It turns out that the red thingies with an X in them are called error markers, and you can manually call the set-error-markers command (hit Esc to get the SlickEdit command prompt) to make them show up.  (I didn’t want to have to do this manually every time I build, though it is pretty intriguing to have access to such business logic functions.)

In the end, I was able to get the error markers to show up automatically again…by simply restarting  SlickEdit.

Acknowledgments

These posts to the SlickEdit forums helped me get to the right terminology and find the set-error-markers command.

I needed to add a tag file

I’m trying out SlickEdit as my C++ code editor.  There are cool things it enables you to do quickly with keyboard shortcuts.  I have seen co-workers do enough that I was convinced to try it.

So far, though, I’m a SlickEdit newbie, so when I tried to navigate from a use of a class class name to the definition of the class and got errors like this:

I wasn’t sure what to do.  I did rebuild the tag file(s), seemingly to no effect.

Tags

According to the SlickEdit help file, tag files are “a database of symbol definitions and declarations®” — basically it lets you jump around from a symbol definition to references to that symbol, and from a symbol reference to its definition.  And I lacked an understanding of the current state of my tag files.

Understanding, Solving

I read the help for context tagging.  You can have multiple tag files: one for your compiler’s libraries (which I already had); and other “language-specific tag files”.

I could jump between reference and definition for symbols defined in my current project, and for symbols defined in the C++ standard library, but not for symbols defined in our own shared libraries (which is what I needed most of the time).  Aha!  I needed to create a tag file for our shared libraries, having SlickEdit process the include directory of shared headers.  I did this; now I can navigate to definitions that are in our shared libraries.

Then I found it in the help page that I had been reading:

You should create a language-specific tag file for any library that is not a compiler-specific library or part of the codebase you are editting. For example, you may have local libraries that are reused from project to project.

I think the reason you don’t have to create a tags file for the part of the codebase you are editing is that for that part you would have a SlickEdit project file and I think that handles the tagging automatically.