In Part 1, we went over how to create a macro from scratch, load it and bind it to a key. We also went over some basic macro functionality like inserting a new line of text and determining which language we are working in. I thought it would be useful to stick with the theme of writing a macro that could insert some useful code. In this blog, we’ll write a macro that surrounds the currently selected block of code with some simple code that reports how long the block takes to execute. It’s sort of a poor-man’s performance tuning, and everyone needs to do it from time to time when they need to determine how long various sections of code take to execute, but don’t want to instrument the whole code base.

Working with selections

The very first thing I realized when I sat down to do this was that I’d need to get the bounds of the current selection, and I’d never worked with selections before. Whenever I hit an area that I’m unfamiliar with, the first place I go is the API documentation. To get there, you can click Help > Contents, and then click API Documentation at the bottom of the contents list. Next, select Macro Functions By Category and you will be taken to a categorized list of the documented Slick-C functions. I scrolled down and found the Selection Functions category in the list, clicked it, and started looking through that list for potentially useful ways to get the bounds of the current selection.

Right away, I noticed _get_selinfo() and it looked like a perfect fit. The problem that I discovered though, is that _get_selinfo() doesn’t provide line numbers for the current selection, only column numbers, which made it useless for the information I needed. I then decided to look at how other macro functions were using _get_selinfo(), so I right clicked it and selected “Goto reference to _get_selinfo” which lists all of the places in the macro code where it’s called. You can also use the find-refs command for this. This led me to other code that used _begin_select() and _end_select(), which I had passed over in the help originally because they sounded more like actions than a way of getting selection information. My strategy for getting the line range was to call _begin_select(), which places the cursor on the first line of the selection, and insert a line of code to get a timestamp. I would then do the same thing with _end_select() and insert the code to get a second timestamp and report the difference.

Writing the macro

We’ll start by beginning a new macro file the same way we did in Part 1, and we’ll call it “insert_debug_timer.e”. Using our selection strategy, we can write the following macro code:

After loading this, you can select some text in your editor, run insert-debug-timer() and your selection will be surrounded by the text “This is the beginning” and “This is the end”. Success! Now we can move on to inserting the actual code that will do the timing. There will be two parts to this, the code that gets inserted before the selection, and the code that gets inserted after the selection. I first made a throw-away command to test what the code might look like (in Slick-C):

Let’s start with the code that gets inserted before the selection. We know that we’re going to have to detect which language we’re in and insert something different based on that, just like we did in Part 1. I didn’t want to pollute the code in the insert_debug_timing() command, so I decided that I’d make a separate function to insert the “before” code. This function will take the indentation text as a parameter and directly insert the text at the current line.

Next we can write the second function, which is basically the same as this one, except that it inserts the code to take a second timestamp, diff the two timestamps and report the time difference. We now replace the lines in insert_debug_timer() with calls to these two functions. We now have a command that takes the current selection (or the current line if there’s no selection) and wraps it with timing code.

A final improvement

This is a good start, but there are a small improvements I had to include. The problem I ran into after about 10 seconds of using the macro is that if you have more than one section you want to time, you get a variable name collision. Since these debug timing code inserts are really just temporary, we can name the variables anything we want. I decided to make a global int variable called g_debugVarCounter that we could append to the variable names every time the insert_debug_timer() command is called, and then increment that value at the end of the command. Here is the declaration of the global counter:

and here’s how we can use it to make the variable names:

Now we can insert debug timing commands wherever we want and there are no variable name collisions. The insert-debug-timer() macro is ready to be bound to a key combination by clicking Tools > Options, then go to Keyboard and Mouse > Key Bindings in the options tree, just like we did in part 1.

One of the things that we think sets SlickEdit apart from other editors is the amount of customization you can do to it. If you aren’t happy with the way something behaves, chances are there’s an option to change it. In addition to the standard settings available in the Options dialog, there’s the fact that much of SlickEdit is written in macro code. This allows for an entirely new level of customization and functionality tailored to the way you work.

Unfortunately, only the most advanced of the advanced users ever consider getting so deep into an application that they learn to write their own macros for it. There’s a few reasons for this. Many people don’t even know that so much functionality is available in macro form. Even if a user did look into making their own macros, finding out what functionality is available in macro code is an enormous challenge. We all have deadlines and important things to do, and learning a new code base like the Slick-C macro language just doesn’t realistically fit into most people’s 24 hour day.

I personally love making little knock-off gizmo utilities for things that fit my workflow. One of the things that I do often is putting debug statements at various points in my code to report the value of some variable. This is very helpful when you want a history of values, not just a one stop breakpoint in the debugger. I decided to make a macro that adds these statements automatically given the word under my cursor (assuming it’s a variable). It’s a simple, first-step macro, and instead of just posting the code, I’m going to walk through the steps to make it.

Starting a macro from scratch

To start, click File > New Item From Template. This will bring up the “Add New Item” dialog. Select Slick-C in the “Categories” tree, select a location where you’d like this file (a scratch development folder is best), and enter insert_debug_value as the name.

Click the Add button. This creates a new file called insert_debug_value.e in the specified directory. This file will be opened in a new buffer with the following code included:

This is the basis for all macros started from scratch. You can load it hitting the escape button to go to the command line, then type “load” and hit enter.

SlickEdit will respond by reporting “Module(s) loaded” in the status area at the bottom of the application. You can now type “insert-debug-value” on the command line and your new command will execute. Of course, it doesn’t do anything yet…

Implementing the macro

A general strategy for this function will be the following:

Get the current word that the cursor is in.

Determine which language is being edited.

Insert a new line beneath that to output it’s value.

That seems simple enough. To start, we’ll use the cur_word() function to determine the full word beneath the cursor. This function has a byref parameter, which returns the beginning column of the current word, so we have to pass a temp variable for that. We can also use the say() function to report the value of curWord to the stdout window. The code currently looks like this:

Again, you can reload this by hitting the escape button to go to the command line, then type “load” and hit enter. If you run it from the command line, it will show the stdout window titled vsapi.dll, and the value of curWord will be shown.

Now we can start to build the text that we’ll insert. Since we want this inserted line to be indented to match the current line, we’ll get the current indentation using the first_non_blank() function. This puts the cursor on the first non-blank column on the line. Next, we’ll get the column number using the p_col property. We can build an indentation string using the indent_string() function, passing the starting column value. The code now looks like this:

For this example, we’ll support three languages; Slick-C, C/C++ and Java. To tell which language we’re in, we can use the p_LangId property, which returns the language ID of the current editor. We can switch on that value and append the code to the variable containing the text to insert. Finally we can call insert_line() to insert the text we’ve built.

Go to the command line and reload the file by typing “load” and hitting enter. Now put the cursor on a variable in the editor, go back to the command line and type “insert-debug-value” and hit enter. A say() statement will be inserted into the file on the line after the cursor that reports the value of the variable your cursor was on. Now you have a way to quickly add a debug statement to your code to report the value of the variable without having to write anything. A final improvement is to store the original line number and column so they can be restored after the new line is inserted.

Binding a key combination to your macro

A macro like the one we just made works best when bound to a key, since we don’t want to have to go to the command line every time we want to invoke it. To bind a key combination to this macro, bring up the options by clicking Tools > Options, then go to Keyboard and Mouse > Key Bindings in the options tree. Type the name of the macro in the “Search by command:” text box to find it. Double click its entry to bring up the “Bind Key” dialog. We’ll bind it to “Ctrl+Shift+/”. Press that key combination and it will appear in the “Key Sequence:” dialog. Click the “Bind” button to bind it. The key bindings entry should look like this:

Is it perfect?

Absolutely not! There are many potential problems here. The cursor may not be on a variable. The buffer may be read only. There are also many other languages that this macro could support. The list is potentially huge. However, this macro is a starting point from which you can start to tinker around with writing your own macros. Soon, you’ll be amazed at how much can be done with Slick-C that you’ll start writing lots of little tools and utilities that fit your own unique workflow. Check back for more blog posts in this series, which will build on what we’ve started here.