Let’s assume you have some file extension which is not already set up accurately in the default SlickEdit Core configuration. It might be something your company only uses internally. Let’s use .data for this example.

I have a workspace created which includes some .data files, and what I first see in the Navigator view is this:

When I go to open one of these files, Eclipse will use the standard Text Editor because it does not know better:

Not terribly useful…clearly the SlickEdit editor has not been opened, and we have no language support whatsoever. These appear to be COBOL files…so we should set up Eclipse to recognize them as such, and also tell SlickEdit that these files should be treated as COBOL code.

The first step is to go to Window > Preferences > Editors > File Associations and add *.data as a “New File Type”. Then select *.data in the list and click the Add button in the “Associated Editors” pane. Now select “SlickEdit Editor”. Make sure you mark “SlickEdit Editor” as the “Default” editor for this file type. Now we have told Eclipse to open all .data files with the SlickEdit Editor.

We are not quite finished yet. Now we need to tell SlickEdit to treat these files as COBOL. So, go to Window > SlickEdit Preferences > Languages > File Extension Manager and create a new extension for data (just data…not *.data), and assign the language to be Cobol 85. Click “OK”, and then click “OK” on the SlickEdit Preferences dialog. Now when you open up one of these .data files, you will see the correct editor opened with the correct language support.

Since the Eclipse IDE has become so popular for mainframe developers, we have been dedicating more and more resources to our mainframe language support. The SlickEdit editor is even now integrated into the Compuware Workbench:

Supports a vast array of programming languages for source code editing, powered by SlickEdit.

PL/I is one of the mainframe languages that got a major support upgrade in the newly released SlickEdit Core v3.7.1. The SlickEdit editor now has full support for parsing structures, includes, and even statement level tagging for PL/I code.

SlickEdit Core also has great support for COBOL, JCL, REXX, and other languages. If you are a mainframe developer coding in an Eclipse-based environment, try out the latest version of the SlickEdit Core plugin for free.

SlickEdit is an MDI application
While there are some very well known applications that support a multiple document interface on the Mac, there is no real standard for how they should look and feel. Each application has a slightly different interpretation. As such we have chosen to keep our MDI implementation very close to what we have used in recent versions.

SlickEdit does a lot
This mostly affects how we present our application configuration options. Most Mac applications have a relatively small Preferences pane, perhaps with half a dozen categories, and a half-page screen of options for each category. But SlickEdit has 20+ years worth of features and configuration settings. Developers come to SlickEdit from a wide variety of editing environments, and our users want to be able to mold the application to their tastes.

SlickEdit is not just for the Mac
Like all multi-platform software, we have to make trade-offs between what might look best for a particular operating system, and what makes the most sense for a feature that needs to work on all of the supported platforms. There is also quite a bit of bias toward keeping functionality and appearance consistent with what long-time customers want and expect. SlickEdit has always placed a premium on letting you work with multiple languages on disparate platforms without having to retrain your brain and fingers. When implementing and tweaking features, we are constantly evaluating what a Mac user would expect, and what a SlickEdit user (regardless of platform) would expect.

SlickEdit will continue to evolve
While we do want to keep our product familiar across platforms, we aren’t going to be sitting stock still. While our immediate focus for the Mac is improvements to Objective-C language support, and better interoperability with Xcode project formats, we are looking forward to changes we can make in the user interface to improve effectiveness and efficiency. Getting this first non-X11 release ready was a big effort. And now that it’s almost done, we’re looking forward to making it the best it can be. We’re excited, and we hope that you will be too.

If you haven’t yet taken a look at SlickEdit 2011 for Mac, we invite you download our most recent beta version.

In order to become a better golfer I decided to start from scratch, beginning with lessons from a PGA pro and purchasing a set of clubs suited to my ‘experienced beginner’ game. And in the process I have found some interesting parallels between learning to golf (again) and learning to use a code editor.

You need solid fundamentals as your foundation
Having been a badly-self-taught golfer for the majority of my life, I now see them all the time at the driving range. And it always starts with the hands. If you have a lousy grip, you’re going to have a lousy swing. The corollary in software development in my mind is basic typing and keyboard navigation skills. You can have a talented mind for software development, but if you’re not touch typing your way through source code, you’re making it way too hard on yourself.

Know and use the tools available to you
I recall a time when my high school golf coach, in a effort to make a point about club selection (or perhaps just to show off), played a few holes with just a 3 wood, a 7 iron, and a putter. This is eleven clubs fewer than you’re allowed to carry. We got the point he was trying to make, but you don’t see good players with fewer than 14 clubs in the bag. And they aren’t using the cheapest off-the-shelf sticks, either.

I also recall a PDC conference session several years ago where the presenter was banging out ASP.NET examples and frequently used Notepad to tweak some of his prepared code snippets. The audience started tuning out about the 5th time he had to repeat the edit-save-compile cycle on a particularly troublesome sample, when the use of any decent code editor would have shown the syntax error at the top of the file right away.

Master the basics so you can focus on the harder tasks
Once you have a solid, reliably repeatable golf swing, your mind is free to focus on all the other details of the game. A software developer that is in command of his or her IDEs, editors, debuggers, etc is likewise free to focus on the real work of designing and coding.

Everybody’s “key move” is different
One night at the driving range I was having a terrible time making clean contact with the ball, even with the deliberate practice of what my golf coach and I had just gone over in the previous lesson. But somewhere in the recesses of my memory I pulled out a tip I had read in Ben Hogan’s Five Lessons where he recommends a wrist waggle as part of the pre-shot routine. So I gave it a try. Lo and behold the waggle made it quite evident that my stance was too close to the ball. After making the adjustment, everything else fell into place. Now I don’t swing a club without this waggle routine.

Most software developers have their favorite features and shortcuts in their editor of choice. These features become an essential part of how they navigate a source base or edit code. My key move in SlickEdit is using the SlickEdit command line. It’s the first place I go when I want to do a quick search, compare the current file with Subversion, look up a keyboard shortcut, and dozens of other operations. Other folks swear by aliases or custom macros. Some will create custom key bindings for every conceivable editor operation.

Demo clubs are awesome
I tried out half a dozen models of clubs before finding the set that I liked the best and felt right for my work-in-progress swing. If you’re not yet carrying SlickEdit in your tour bag, we invite you to download a trial and take it out on the range.

Few companies and few developers like to talk about the warts in their software, but let’s face it — for decades, SlickEdit has been a single threaded application, nothing but a bicycle-built-for-one. That single thread rode high and strong and did what it wanted, with all the powers and dangers of the world granted to it to do as it pleased. Let’s call this thread George, King George, as it was.

Then we decided to let another thread into our world. Well, needless to say, King George did not like this newcomer in his kingdom. Suddenly, he had to synchronize his peddling and braking and balancing with another thread, and let me tell you, he was not used to doing so much paperwork. Sorry, George, you have to acquire a Mutex before you can use the memory allocator. Sorry, George, you have to release the Mutex when you are done. George was angry, frustrated, and not accustomed to waiting in line behind these mere peasants. They were supposed to make his life easier. Instead, they pervasively filled his kingdom with landmines. George had to step carefully from now on. His smallest comfort was that those little threads also had to step carefully, very carefully. The King was also comforted to know that there still were places that only he could step.

Converting a single-threaded piece of software into multi-threaded software is a task that requires vision. It also requires strictness and thorough investigation of what-calls-what and what-uses-what. The vision comes from finding ways to utilize asynchronous processing and deciding what parts of the application to make thread safe first. The vision also comes from learning new ways to design less stateful APIs and data structures so that you can minimize access to shared data, or at least make the access thread-safe.

It can’t be done all at once.

The techniques for writing thread-safe software and multi-threaded software in general are well documented. It is certainly not a new science, but each thing you convert poses new challenges.

My challenge in SlickEdit 2010 and SlickEdit 2011 was to make it possible for a thread to parse code and insert indexing information into a tag database. Well, that certainly can’t be real hard. That is, until you meet King George.

Step 1: A thread that parses code

SlickEdit has great parsers for many, many languages; the problem was, none of them were written in a thread-safe manner. The lexical analyzer framework was completely stateful and also lacking in flexibility and power. Every parser would need a new lexer, and it had to perform well. The invocation mechanism depended on the Slick-C interpreter, which is still far away from being a thread-safe component. The parsers used global data when they wanted to and communicated directly with the database. To make a long story short, a lot of code had to change.

Step 2: A tagging job queuing framework

Once we could parse code, we couldn’t just start creating threads all willy-nilly. We needed a block of threads to do the work and pass the results forward to the editor. We needed to define what a tagging job was and how the indexing information was collected. We needed to reconsider every place where the editor would launch tagging jobs and see if those jobs could be done on a thread. As it turned out, the answer was “nearly everywhere”. Oh, by the way, King George liked that.

Step 3: A thread-safe tag database

This is one of the big steps forward in SlickEdit 2011. A thread can write to the tag database, making it possible to do everything required to build or update a tag database completely in the background. This was no easy task, because the tag database is a sophisticated component that was built specifically for King George. We had to rethink how we traversed through items in the database. We had to get rid of shared global variables. We had to refine the database block cache so it could be shared by threads.

Step 4: Getting a list of files to tag on a thread

The final step was to scale the threading up from allowing the main thread to schedule jobs one at a time to having a thread schedule a a list of files to be tagged. We needed this thread to find all the files in your workspace, check dates, figure out what language the files were, and finally schedule anything that was new or out-of-date to be tagged. This meant rewriting a lot of single-threaded Slick-C code as thread-safe C++. The speed gains from this change were significant.

The final result

SlickEdit 2011 is a huge improvement over SlickEdit 2010 with respect to its handling of background tagging. King George is beginning to appreciate what these little threads are doing for him and how they are making his job easier now.

The worst problem: Mutex acquisition order

This is what I regard as the worst thread-safe code synchronization problem. Now, if you are fortunate enough to be writing thread-safe code from scratch, where you have an existing, clearly modularized code whose critical sections are small, short-lived, and well encapsulated, it is not a problem likely to hurt you unless you do something silly. But, when you have a large base of single-threaded code with large amounts of shared data that you have to try to make access to thread safe, things get ugly really fast. Here is the classic deadlock condition.

   VSMUTEX mutex1;
   VSMUTEX mutex2;

In the main thread, King George does this.

    mutex1.lock();
    ...                        // I own mutex1 and rule supremely
    ...                        // except that I don't own mutex2 yet
    mutex2.lock();

In another thread, some peasant does this.

   mutex2.lock();
   ...                          // I own mutex2, nobody else can have it,
   ...                          // not even my reverent King
   mutex1.lock();

When King George has mutex2 and is trying to get mutex1, and simultaneously, another thread has mutex1 and is trying to get mutex2, they will deadlock forever. There are a few ways around this, but the best way is the classic solution of don’t do that. The problem is that it is hard to see how pervasive this problem can be when some special case, such as error handing, causes everything you think you know about what order you acquire Mutex’s in to be reversed. This is a problem that can only be solved with thorough analysis and testing and fundamentally sound designs. But, given the circumstances surrounding migrating older single-threaded code to support threading, such designs are harder to come by than one would hope.

Summary

If you read this whole thing looking for deep insight on how to write solid thread-safe code, well, you probably finished sadly disappointed. If you are planning on renting a bicycle built-for-two with your spouse and were looking for riding tips, then you really, really read the wrong article. If you came here because you always thought SlickEdit should do tagging in the background and wondered why it took us so long to implement it that way, then maybe now you understand the obstacles and hurdles a little better. We are still iteratively improving the system and working to improve the tagging throughput. You can look forward to seeing even more performance gains and scaling in the first update (16.0.1).

SlickEdit is moving forward, and finally, George isn’t the only one peddling the bike.

CodeProject

• 64-bit Versions for Linux and Windows
• Multithreading the Context Tagging Engine and Auto-Reload
• Support for Ruby Debugging
• Support for Git Version Control
• Dynamic Debugger Enhancements
• Updated Microsoft Visual Studio 2010 Support
• Updated JUnit Support
• SlickEdit License Manager

So what happened? Choosing what goes into a release is the toughest job for a product manager; there is never enough time to develop everything we’d like to get done in a given year. So we have to make hard choices.

We look at our customer base as a set of constituencies, each with different needs and change requests. Each language we support represents a different constituency with different needs, likewise for each platform. Fixing a tagging problem in C++ does little to help a Python programmer and vice versa. Some features, like Backup History, introduced in SlickEdit v9.0, are useful no matter what language or platform you are using.

Another way to divide constituents is into existing customers and new customers. Generally speaking, new features are considered more helpful in going after new customers, while bug fixes are aimed at existing customers. One consistent piece of feedback from existing customers is that they don’t really want new features; they just want the existing features to work better. In each release, we try to strike a balance between features to lure new customers and bug fixes for existing customers.

When we made the feature plan for this year, it became clear that there were parts of SlickEdit that really needed updating. As a product with a very long history—the first version of SlickEdit was released 23 years ago—we have seen some dramatic changes in the platforms we run on and the expectations of our customers.

In the early versions, resources were scarce so you needed to be as lean as possible, use as little memory and CPU as you can. This also makes your program very fast, which is one of our top goals. Now, a typical development machine has 4 cores and 4GB of memory or more. In this environment it’s frustrating to wait for an answer while the program is only using 25% of your available resources. That’s why the multithreading work was so important.

Don’t get me wrong. We’re not out to become a resource hog. We do believe that, for programmers, coding is the most important thing they are doing and that sufficient resources should be brought to bear.

As code bases grow, it’s even more important to have an editor, like SlickEdit, that knows the location and type of your symbols. Being able to generate that information efficiently and access it quickly is always our top priority. SlickEdit 2011 is a big step in giving you the fastest possible code navigation.

A SlickEdit user thought it would be nice to have SlickEdit displayed on his bookshelf, so we sent him an image and he created his own homemade SlickEdit box. It looks great!

Say you are using Eclipse as shown here (Eclipse 3.6.1), and you want to open another view of the same file.

You can do this easily within Eclipse by using the “New Editor” command. Right-click on the buffer tab of the file and select “New Editor”. For faster access, you should bind this command to a key, or use the mnemonic Alt + W, E for the Window menu. This allows you to create a new editor window without ever having to reach for the mouse. Good so far…but what did we get?

Not really what we wanted, because this is pretty useless. We want to be able to see a side-by-side view of these windows. How can I accomplish this in Eclipse? Well, unfortunately, you have to reach for the mouse. You have to click and drag the buffer tab for one of these windows over to where you want it to be. Then you get what you really want.

With SlickEdit Core for Eclipse (v3.6.1), you can accomplish the same thing very quickly, without ever reaching for the mouse. This might seem like a very small detail, and maybe it is to some folks, but if you try to limit (or eliminate ) your mouse usage, you will find that you are a much more comfortable and productive programmer.

If I have the same file open in Eclipse 3.6.1, but this time using the SlickEdit Core 3.6.1 plugin, I can run the command vsplit-window from the SlickEdit command line, and a new editor window is opened to the right of the current editor window. No intermediate step involving the mouse. Of course, you should bind vsplit-window to a key to be more efficient.

vsplit-window demo

SlickEdit Core also has a command for hsplit-window (Ctrl + H by default) for splitting an editor window horizontally, and you can use next-window (Ctrl + Tab or Ctrl + F6 by default) to rapidly switch between all open editor windows.

There are other plugins available which provide similar functionality. I believe there is an Emacs plugin out there which supports the Emacs-style Ctrl X, 3 window splitting, which also does not require the mouse. But no plugin also provides the level of language support of SlickEdit Core. And SlickEdit Core does have a fully functional Emacs emulation, for any Emacs users out there who want to be able to Ctrl + X, 3 within the Eclipse environment.

In programming, however, the mouse can be one of the greatest productivity sinkholes. Time is wasted each time you lift your hand from the keyboard to grab the mouse, and more time is wasted when you move your hand back to home row in preparation for more typing.

So what’s the solution? Keep your hands on the keyboard! To do this use the SlickEdit^® command line and bind commonly used commands to keys.

Launching Operations
SlickEdit provides three ways to launch operations: key bindings, commands, and menus. OK, there are actually four, if you include icons. Since the focus of this article is how to keep your hands on the keyboard, I was going to skip that one.

Key Bindings
Key bindings are the fastest way to launch an operation. They can be pressed at any time while editing. A key binding associates a key sequence with a command. A key sequence is a series of key strokes. Anything you do frequently should be bound to an easily remembered key sequence.

For example the key sequence Ctrl+A means hold down the Control key, typically labeled “Ctrl” on most keyboards, and press the A key. The letter A is represented as an uppercase letter, but this does not mean that you are to press the Shift key. If you are supposed to press the Shift key, the sequence will be written as Ctrl+Shift+A.  We use the uppercase A to match the letter on the keyboard.

Commands
Commands are useful for less frequently used operations or operations that take arguments. They are executed from the SlickEdit command line and are nearly as fast as key bindings. Press the Escape key (in most emulations) to activate the command line, which is displayed at the bottom of the SlickEdit application window. 

  Figure 1, SlickEdit with Command Line

It offers a full command history and completions for command names and arguments. Use the arrow keys or the mouse to scroll through previous commands. As you type, a list of possible completions is displayed. Use the arrow keys or mouse to select a completion. SlickEdit stores recorded macros as commands. You can also use Slick-C to write new commands. Use the _command keyword to identify a macro as a command. Any command can be bound to a key sequence for faster launching. 

Menus
Menus are accessed via the mouse or a keyboard shortcut. Menus are great for infrequently used items that may not be worth a key binding. They are also helpful to learn about new capabilities. But if you use an operation frequently, you will be more productive by binding it to a key sequence or launching it from the command line. Many menus list a keyboard shortcut to launch the operation. This is just the key binding for the associated command. So when you use a keyboard shortcut, you are really just using a key binding.

You can also operate the main menu through hotkeys. Enable the use of hotkeys by selecting Tools > Options > General, selecting the General tab, and putting a check in “Alt menu hotkeys”. This will be selected by default in many emulations. Once enabled, pressing the Alt key will display an underscore beneath each menu option, indicating the letter to press to activate that option. This is not as fast as key bindings, but it does keep your hands on the keyboard and is much faster than using the mouse. In some cases the menu hot key sequence is a good mnemonic for the command. For example, Alt+P, E (to bring up Project > Properties) may be easier to remember and type than binding project-edit to Ctrl plus some function key. 

Icons
SlickEdit presents icons in a series of toolbars related to different tasks. Toolbars can be customized with an extensive set of additional icons. Icons are useful for die-hard mouse users or for setting up infrequently used operations for which you have a hard time remembering the associated command or key binding. 

The Golden Triangle
The three methods (excluding icons) to launch an operation are related, forming the Golden Triangle of operation launching. If you know how to execute an operation with one of these, you can easily configure SlickEdit to launch the operation using the other two methods. Commands form the base for the other two…which is why it is shown as the apex of the triangle (Damn it, Jim, I’m an engineer, not an artist!). Maybe I should have used a Golden U or something. 
 

Figure 2 the Golden Triangle; behold its majesty!

From Key Binding to Command
Sometimes you may want to change the key sequence to which an operation is bound. You first need to find the command associated with that key sequence. Use the what-is command from the SlickEdit command line or select Help > What Is Key from the main menu. The command line will be replaced with the prompt, “What is key:” Enter the key sequence in question, like Ctrl+A (hold down the Control key and press A), and SlickEdit displays the associated command. In CUA emulation, SlickEdit will output, “Ctrl+A runs the command select-all”. You can use the same approach to determine the commands associated with mouse events. After you run what-is, click any mouse button and you will be prompted with a list of mouse events. Select one from the list and SlickEdit displays the associated command. For example, if you select mbutton-down in CUA emulation, SlickEdit will output, “MButtonDn runs the command mou-paste”. 

From Command to Key Binding
To find the key binding for a command, use the where-is command or select Tools > Options > Key Bindings from the main menu. The where-is command works just like what-is, except you type in the command name and it outputs the key sequence. The Key Bindings dialog displays a list of the commands. You can scroll through the list or search for a command by typing the command in the text box at the top. The key binding for the selected command is displayed in the dialog.  

Figure 3, Key Bindings Dialog   

Modifying Key Bindings
The Key Bindings dialog can also be used to set a key binding. Type the command in the Command field, or select one from the list. Then click the “Add Key or Mouse Click” button. Now type the key sequence you want to use. For example, to bind a command to Ctrl+A, hold down the Control key and press A. To bind a command to a mouse event, click any mouse button and then select the appropriate event from the list. When you are finished, click the Bind button. To exit the dialog, click Done.

From Menu to Command
If the menu entry displays a keyboard shortcut, you can quickly find the associated command using what-is and entering the key sequence. If the menu entry does not display a shortcut, then finding the command for an entry involves a little more work.

SlickEdit provides a convenient UI under Macro > Menus that allows you to view and modify menus in SlickEdit. To find commands for the items on the main menu, select “_mdi_menu” from the list and then click the Open button. You are presented with a menu hierarchy that you can expand to find the menu entry in question. Once selected, information about the entry is displayed including the command executed. You can use this menu to add or change the shortcut for a menu item. Doing so has the same effect as using the Key Bindings dialog to bind the menu entry’s command to a key sequence.   

Figure 4, Menu Editor

Some menu entries are added dynamically by SlickEdit, so you may have to search the code to find the associated command. One example of this is Build > Java Options, which is only present when a Java project is active. Unfortunately, finding the associated commands for these entries can be very difficult and not easily covered in an article like this.

Context Menus
It is also easy to find the commands in the context menu for the editor window. The context menu, itself, contains an entry to “Edit This Menu”. Selecting this option brings up a dialog that lists the menu entries and associated information, including the command. Use this dialog to modify the context menus. Note that there are two context menus for the editor window: one when a selection is made and one when no selection is made. You can view or change the function that is used for these menus by selecting Tools > Options > File Extension Setup and selecting the Advanced tab.

From Key Binding to Menu and Back
Menu entries map to key bindings through commands, so key bindings are not directly associated with menu entries. To map from a key binding to a menu or vice versa, you need to look up the associated command. That Golden U is looking better all the time!

Customizing Toolbar Icons
The focus of this article has been to help you keep your hands on the keyboard, so icons weren’t included in the Golden Triangle. Besides, then I would have needed a Golden Square or some other form of rhombus, and that just doesn’t sound cool. You may find it helpful to change the set of displayed toolbars, add or remove icons, or change the behavior for an icon. SlickEdit uses the term “toolbar” to refer to both icon bars and tool windows. To change the set of displayed toolbars, select View > Toolbars and check/uncheck one of the listed toolbars.

The list is divided into two groups. The top group is comprised of tool windows, like the Symbol view and the Projects view. The bottom group is made up of icon bars.

Additional options are available on the Toolbar Customization dialog by selecting View > Toolbars > Customize. The Toolbars tab provides a way to control the visibility of the toolbars. The Toolbars tab allows you to set options for which toolbars are visible, whether they are dockable, etc.

The Categories tab displays the complete set of available icons. These can be added to any icon toolbar by dragging them to the desired location. All of the icons have pre-defined behaviors, except the set in the “User Definable Tools” category. Use these to add your own functionality.

Each icon has an associated command that defines what happens when it is clicked. To view or change that command, right-click on the icon and select Properties. The icon needs to be located in a toolbar to do this. You cannot access the properties for an icon in the Toolbar Customizations dialog.  

“Exit, Stage Left”
OK, that one is a Snagglepuss reference[ii]. Whatever angst I previously expressed for mice has now been transferred to the Golden Polygon of Unspecified Dimensions. Regardless of the shape, you now have the tools you need to configure SlickEdit to work the way YOU think it should, using the key bindings you find natural. This is one of the essential steps in being a true power programmer.
 

[i] Mr. Jinks, sometimes called “Jinks the cat”, appeared in the “Pixie and Dixie” cartoons as part of “The Huckleberry Hound Show”, by Hanna and Barbera.

[ii] Snagglepus is another of Hanna-Barbera’s cartoon characters.

In the article he discussing some of his favorite features of SlickEdit and why SlickEdit is his code editor of choice for programming.

On objections on switching editors

If your current editor works well enough for you, why switch? The answer depends on how you define “well enough.” Your current editor probably handles every editing command you think you need now, but consider the possibility that something could make you far more productive. You’ll see a few examples in a moment, but first, here are some of the reasons you might decide not to switch editors.

Regular Expression Search and Replace

This isn’t an exclusive SlickEdit feature, some other editors have it too; but if you haven’t had the opportunity to experience regular expression searches, you should really consider switching to an editor that supports the feature.

Macro Record/Playback

SlickEdit carries out many of its commands through its slick-C programming language (note that both Brief and Emacs have their own languages as well). SlickEdit lets you write your own macros, or do a simple record / playback. This comes in handy when the syntax for find and replace gets too dicey.

Other Features

As you might imagine, because SlickEdit’s been around for 20 years, this article just scratches the surface.

Continue reading Hey, Check Out My Slick New Editor! here: http://www.devx.com/enterprise/Article/42874/0/page/1

In terms of economic stimulus, this could have a much greater effect on the nation. Consider that many programmers use minimalist editors that provide little help to analyze and navigate their code, don’t include powerful completions, or features to cut the number of keystrokes necessary to type their code. If these programmers switched to a more powerful editor, like…oh, let’s say, SlickEdit…their productivity would go way up.

As the productivity of the individual programmers goes up, their projects would get done earlier or include more capabilities. This increases the productivity of the people using that software, which would then increase the profitability of those companies. Since software underlies almost every industry, this could lead to a potential boom, the likes of which hasn’t been seen since the post-WWII expansion. Suddenly, there’s a surge in the US GDP. We pay off the national debt in a few years and have money left over for a comprehensive public health care system.

And it all begins with getting people to switch to a more effective editor.

Unfortunately, SlickEdit isn’t big enough to warrant a special government program like this. We’re not one of those too-big-to-fail kind of companies. But that doesn’t mean you can’t experience your own little economic stimulus.

Look at your coding practices and see if a more powerful editor wouldn’t help you write more code faster with fewer errors. Though the government won’t pay you for switching, the boost in productivity surely will.

SlickEdit is Giving Cash for your Clunky Editor!
Cash for Clunky Editors Program:

If the editor you purchased is lacking the speed, power, and flexibility SlickEdit provides…trade it in for CASH towards SlickEdit.  Call 1-800-934-EDIT (3348) or email sales@slickedit.com, and mention the Cash for Clunky Editors Program to learn about the savings.

The program expires on September 30^th, 2009, so act quickly.

Happy coding,
The SlickEdit Team

Visual Basic 1.0

Sitting in between Turbo Tax ’99 and Mavis Beacon’s Typing Tutor was this gem….  Visual Basic 1.0.  I almost couldn’t believe my eyes.  To me, this was on par with finding the missing link.  As a programmer, this was archeological gold, and it was on sale for fifty cents.  My kids saw the excitement on my face and must have thought that I’d found an XBox 360.  For them, Visual Basic was a major let down.

A lot of people think that VB is soft and if you program in it, you’re automatically a drooling hack developer who couldn’t program their alarm clock.  I cut my teeth on VB 4.0 in my first job, and learned that when combined with COM in C++, VB was a fantastic language for the job of making a user interface. That being said, VB still has some special memories for me.

The contents of the box were practically undisturbed.  The disks were all still in their original plastic wrap and the manual didn’t seem to have ever been opened.  Immediately, there are certain clues that tell you just how old it is (even though the box is copyrighted 1991).  First, the box contains two forms of media; 3.5″ and 5.25″ floppies.  To actually take a 5.25″ floppy out of its sleeve and hold it brought me back to the days of floppy doors and the red LED that told you the disk was being read.  The system requirements for VB 1.0 were Windows 3.0, a 286 processor and 1MB of memory.  Somewhat of a far cry from the Visual Basic of today.

I also loved the included “Companion Products and Services Directory”.  The third party marketing rush had already begun back then.  Most of the components in the catalog, though, are for connecting to a VAX server or to a dBase or Btrieve database.  There are a handful of charting components and widgets such as tree controls (not yet standard in 1991) and grids.  The reminiscing continues.

This box goes right up on my bookshelf at home next to the most revered books in my collection. Say what you will about Visual Basic, but it may be one of the most important developments in programming over the last 20 years for the simple reason that it allowed any non-programmer to write a Windows program.  If you think that’s not a valid reason for such importance, let me repeat… it allowed any non-programmer to write a Windows program.  It was Prometheus, stealing fire from Zeus and giving it to mere mortals for their use.

You no longer had to know C, and wade through Petzold, to write “Hello World” in a window.  Employees from any company with core business knowledge, but no degree in programming, could now quickly write customized applications.  Of course, the debate of whether this was a good thing for programming or not still goes on today.  However, regardless of which side you’re on, you can’t deny that VB was a major victory for bringing the PC to the business market.  Without VB, we may not even have a Microsoft today.

So thank you very much, guy from two streets down, who decided that Visual Basic 1.0 wasn’t important enough to keep, but too important to just throw away.  One man’s junk is another man’s gold, and I really struck it rich that weekend.

Unfortunately I discovered this technique after we finished the documentation and shipped the plug-in, but hopefully me pointing it out here may help some users. 

Also, don’t forget the “Activate Editor” command in Eclipse (F12 by default).  If you are using _eclipse_execute_command to jump into different Eclipse Views and search around mouse-less, hitting F12 will jump you back into the last active editor.

<update> 

Check out this thread of the SlickEdit Forums for adding a generic Eclipse Pass-through Command: http://community.slickedit.com/index.php?topic=3549.0

From the post:
If you are evaluating 3.4.0 for your company, you can make this happen easily.  One of the best features in Core 3.4.0 is the introduction of _eclipse_execute_command, which is discussed in the user guide/readme, and also a little more in my post here: http://community.slickedit.com/index.php?topic=3816.0 .  This is the idea that Rob suggests in this thread.

I’ll take this opportunity to give a brief tutorial on how to integrate that “Activate Task” shortcut into the SlickEdit environment.

First you need to know the command id of what you are trying to execute.  I used the method described http://evans-stuff.blogspot.com/2007/10/it-seems-that-im-not-only-one-still.html , in which you create a Simple Cheat Sheet and use the Command Browse button (see first screenshot).

Then I just used the search field to find the command (see second screenshot).

Now that I had the command/parameter info, I opened up the Slick-C macro file where I write my custom commands (ryan.e), and added functions for Activate Task and Deactivate Task using _eclipse_execute_command (see third screenshot).  Remember to load your macro file with F12 after writing the functions.

Then I used the SlickEdit Keybindings dialog to bind eclipse_activate_task to Ctrl + F9 (see fourth screenshot), and voila.  Hitting Ctrl + F9 in a SlickEdit editor will launch the Mylyn Activate Task dialog.

It may seem like a lot of steps, but it’s really not.  This whole process took me less than 10 minutes including the time I took to capture/crop/annotate the screenshots.  You can use this method to execute almost any Eclipse command from any plug-in from the SlickEdit environment.

- Ryan

I can’t say that I’ve met too many developers that eagerly looked forward to reviewing code. Most developers understand the importance of code reviews, but many have experienced the pain of poorly run code reviews. Although SlickEdit Tools does not have a “code review” feature, it provides several features that can be used together to make a code review run smoothly. A well done code review process can be the difference between developer loathing and developer buy-in.

Because code reviews are such a big topic, this article will focus on some of the steps that lead up to a code review. Code reviews typically focus on the work of a single developer, so we’ll start there. We are going to be code reviewing the developer with ID SLICKEDIT\shackett (or Scott) in source control, and we’ll be reviewing his work since March 3, 2008, which is the date of our last (fictional) release.

Finding the Best Files to Review
Our first challenge involves finding the set of files that Scott has worked on since March 3, 2008. We’ll use the Find Version feature of the SlickEdit Tools Versioning Toolbox as our starting point.

Find Version allows you to query versions of the source code files in your solution. The code review organizer can use this feature to find an ideal set of files to review. Simply click SlickEdit > Find Version to bring up the Find Version tool window. For this example, we’ll find versions with the following criteria:

• Since date: Finds all versions checked in since a particular date, such as the last release.
• Developer name: Finds all versions checked in by one or more specific developers.

These two criteria are used to find all versions checked in by Scott during the latest development cycle (March 3, 2008 – present).

No development team has the resources to code review every file in that list, so it’s important to find the best candidate files to review. Therefore, the next task is to look through the results and find a sampling of files that represent the most important or complex code. You might also include some files that have a high number of check-ins by that developer, which indicates high rate of change, or churn. These are the ideal candidate files to be reviewed. Email the names of those files to all developers who will be participating in the code review.

[Click here for the full size image]

In this example, PackageBaseWhidbey.cs has had several changes and is a very important file, so we’ll include that in our code review process.

Loading the Files to Review
When a developer is ready to prepare their review comments, they should close all other files and open the files in the list sent by the code review organizer. This can be done quickly using the Load Files feature in the Editing Toolbox, which allows you to quickly filter the list of files in your solution and open the ones you’re looking for. Click SlickEdit > Load Files to use this feature.

By typing “basew” in the filter, we narrow down the files in the list to only those that include that text in their file name. We’ll select PackageBaseWhidbey.cs and open it.

Isolating a Developer’s Work
One of the most difficult things to do when reviewing the code of another developer is actually identifying the work that that developer did, especially if it was done as part of a team. Once you have PackageBaseWhidbey.cs open, we’ll use the Version Visualizer feature of the Versioning Toolbox to see which parts Scott has worked on. Click SlickEdit > Version Visualizer to show this tool window. Next, select “Default User Scheme” in the drop down at the top of that tool window.

The versions of the file will be processed and the tool window will list the names of all developers who have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify who wrote each line of the file.

[Click here for the full size image]

You can find Scott’s name (SLICKEDIT\shackett) in the tool window list and double click on it to go to the first line of code he contributed. You can then use the next and previous button on the tool window to navigate through the blocks of his work.

To make Scott’s work stand out more distinctly, select his name (SLICKEDIT\shackett) in the list and click the “Toggle Selection Visibility” toolbar button. When toggled on, Scott’s work will stand out, and all other developer’s work will be dimmed out. This allows you to quickly see what code is Scott’s and what code isn’t. You can click this button again to toggle it back off.

[Click here for the full size image]

Another option is to assign a unique color to Scott. To do this, click the Configure Visualization Schemes button on the Version Visualizer toolbar. This will bring up the Scheme Builder dialog. We’ll create a new scheme to highlight all areas of code worked on by Scott. Click the Add new scheme button and give the scheme a name of “Scott’s code”. We can now add a scheme item for Scott and give it a color of bright red.

[Click here for the full size image]

We can save this visualization scheme and then apply it by selecting it in the Version Visualizer drop down. This same scheme can be applied to any file to highlight areas of the code written by Scott.

[Click here for the full size image]

If you find a block of code written by the developer being reviewed that looks questionable, you may want more context about the developer’s intent, such as the check in comment made when that section of code was checked in. This information is very important for creating meaningful code review comments. The easiest way to do this is to see which version that code was checked in as, and look at the comment associated with that version. To do this, select “Default Relative Age Scheme” in the drop down at the top of the Version Visualizer tool window.

[Click here for the full size image]

Again, the versions of the file will be processed, but now the tool window will list the IDs of all versions that have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify which version last updated each line of the file. The colorizing of each segment corresponds to the age of the version it was checked in with (dark is oldest, light is most recent).

You can find the version associated with the questionable code and take a look at the comments associated with it. You can also use the next and previous button as before to see all of the code in the file that was updated as a result of that check in. For instance, we may have disagreed with the AddMenuCommandHandler function being public. We can see that change was part of version 762. By hovering over that version in the Version Visualizer tool window, we get a better understanding of why the function was made public. All of these features assist the team in making judgments about which code to review. They also provide some insight into the motivation the developer being reviewed might have had when checking a set of code in.

Next is the task of actually commenting on the code. This task is always best done in electronic format, in a way that can be pulled together as part of the code review meeting. The next article in the series will go through some of the features of SlickEdit Tools that facilitate writing comments about code and tying them directly to the source, without modifying the files.

Why is he having so much trouble using my editor? Because I’m using SlickEdit. What does he use? SlickEdit.This scenario happens a lot to me, really anytime a coworker tries to use my machine. Even after he gets used to the color scheme and whatever tool windows I use, if he doesn’t happen to use the same emulation that I use, he’s hosed. He spends more time trying to get somewhere in the code than he does actually making any changes. And no doubt he’s got some custom keybindings on his machine that he uses all the time, but my editor seems to think they have completely different functions.

So the good thing about SlickEdit is that it’s incredibly customizable. You can set it up to do whatever you want, however you want. You can go over, under, around, and through your code using commands and keybindings that you define, and after using them for a couple of days, you’ll feel like you were born using Ctrl+W to comment a line of code. You’ll do all this without thinking about it, because you’re thinking about the code instead of the use of the editor.

Ah, but then you have to use someone else’s configuration. It’s worse if they’re looking over your shoulder, giving you keyboard performance anxiety. You’re all thumbs, two left hands, a DVORAK user in a QWERTY world. Your customizations are your crutches, and you have to limp along to solve a stupid problem when you know it works perfectly on your machine.

In fact, you work perfectly on your machine, too.

The worst thing, though, is having to hand edit HTML that has been generated by other software, be it an Office document or HTML created by web page authoring software. This was the situation I found myself in recently when I was asked to do some simple web page maintenance for a local volunteer organization.

The site was hosted by Yahoo! Japan and was originally authored by Japanese web site software from a major unnamed corporation, which I will just refer to as HAL. I was not given the original project files from which I could make changes and regenerate the html, so I was going to have edit the HTML directly. The Yahoo! Japan portal provides web-based maintenance tools for the sites they host. Through a browser you can see a list of the directories and files in your site, backup and rename files, and edit and save HTML files in an editor control. You could also upload new files. These are crude tools, but for the changes I had, it should have worked. I didn’t want to manually download and upload each page.

I pulled up the first page in the editor control, and started editing. The file was many times longer than needed, filled with obtuse metadata and other unintelligible nonsense. The page switched between English and Japanese frequently, often many times in one sentence, and each change in language required that section to be enclosed in yet another <span> tag with the proper lang attribute. In many cases, a single word was nested in 2 to 3 identical <span> tags. Most lines were about 80 characters wide, but there were also 500+ character lines just to make things interesting. (I hate HTML.) Anyway, without too much trouble, I was able to find the content and make the changes. It wasn’t hard, just tedious.

I was now ready to view the result. I hit save to close the editor control and return to the file list. I switched to another browser tab that had the page loaded and hit F5 to refresh the display. Every bit of Japanese text was total garbage. Argh!!. I inadvertently changed something that ruined the display of the entire page. I knew I’d have to try again and be more careful. So I open the page in the editor control again and much to my chagrin, now all the Japanese text in the original file was garbage as well. The whole page was ruined. It hadn’t just a bug in my edits causing the display to go bad. (Another lesson in why you should back up your content before you start editing. Fortunately I had. Whew!)

I was stuck. A little experimentation quickly revealed that just loading the file in the Yahoo! Japan editor control and immediately saving it still ruined the Japanese. Not very impressive considering this was a site specifically for hosting and maintaining Japanese websites! (To be fair, this did not happen to every page on the site. Most I could edit just fine.) The problem was that the Yahoo! Japan on-line editor control did not resave the file with the correct encoding. It could read the file, display the file, and edit the file, but not save the file correctly. It was actually rather pitiful. Would it have worked had I been running on a native Japanese version of Windows XP and IE? Who knows? I would hope so, but that wouldn’t help me. I had the same problem in IE and Firefox. Could I have changed my browser settings to fix the problem? I don’t know, but I’ve never had a problem with any other Japanese page.

I was about to resign myself to having to recreate the whole page from scratch and upload it. Then I remembered SlickEdit handles different encodings. So I pulled up the backup copy in the Yahoo! Japan editor control and opened a new blank HTML page in SlickEdit and selected Japanese (Shift-Jis) encoding. After a simple copy and paste into SlickEdit, I had the original contents in a real editor (syntax highlighting, completions, HTML beautifier, parenthesis matching etc..) that could preserve the encoding. In a lot less time, thanks to the features in SlickEdit, I had the changes in again, saved properly to Japanese (Shift-Jis), and uploaded back to Yahoo! Japan.

Thank you SlickEdit.

(But I still hate software generated HTML.)

The book is a symbol of the impact our work has on others. It says that there are enough people using SlickEdit for a publisher like Wrox to publish this book. That someone like John, whose knowledge of SlickEdit is remarkable, was available to write this book also indicates something of the passion our customers feel for our work. This awareness of the positive effect our work has had on others is often missing in software development.

I’ve worked on a lot of different projects in my career. Most were large custom automation jobs that were deployed on a server somewhere. Often there was little to no interaction with the actual users of the system. With SlickEdit, I get to see and use the result of my efforts. I interact with people who use our products every day. And now, with the release of Professional SlickEdit®, I feel, well, almost famous.

Why a SlickEdit Book?

The very existence of a 3rd party book on SlickEdit raises the question of why such a book is needed. Some might ask, “Isn’t the user guide good enough?” The answer, frankly, is “yes it is” and “no it isn’t”.

After 20 years of development, SlickEdit is full of features. Even though we’ve made great strides in improving our documentation over the last several releases, there’s still a long way to go. As John points out in the introduction to Professional SlickEdit®, “The SlickEdit User Guide that is shipped with the product does not even document every feature…” Hey! We’re working on it!

The SlickEdit User Guide and Professional SlickEdit® describe SlickEdit from two different perspectives. Our goal with the User Guide is to teach you how to install, configure, and use the features in SlickEdit. Professional SlickEdit® picks up where the SlickEdit User Guide leaves off. It covers many of the features that are documented in the user guide but it does so from an advanced usage perspective, showing effective ways to use the features. The book includes examples showing actual code and how various features can be used. It also includes sample Slick-C macro code to customize and extend SlickEdit, which will be of particular interest to advanced users.

We try to be process-agnostic at SlickEdit. We recognize that people have very different work patterns, and we don’t want to force you to change them. Instead, we believe it is important for SlickEdit to adapt to your work style. No matter how much we are convinced that brace style 1 (shown below) is the only sensible choice we allow you to mess up your code with brace style 2 and 3 as much as you like.

As an independent author, John had more degrees of freedom. He was freer to express his opinion, not unlike the freedom one has while blogging. So, where our documentation provides a list of the capabilities, John directs you towards the ones he finds to be most useful.

A Fresh Perspective

One of the key benefits I’ve gotten from this process is the insight from seeing our product from another perspective. Working with John and reading his descriptions of SlickEdit helped me see the product in a new way.

It’s a common problem. The more you work on something the less you are able to really see it. You see, instead, your perceptions of the product. How many times have you written something, code or text, and missed a simple flaw, like an omitted word or a boundary condition? No matter how many times you read it, you see what you expect to see not what is really there. Then, someone who reads it for the first time easily finds the problem.

My thanks to John Hurst for writing this book and the good people at Wrox for publishing it. And for treating me to a truly rewarding moment in my career!

[1] Professional SlickEdit® by John Hurst (ISBN-13: 978-0-470-12215-0), Wiley Publishing, Inc.

I’d heard that before; resistance to change for fear of change. It’s like being told, “because I said so,” by your parents for lack of a good reason. I always saw that guy as being an obstacle in our software development, more interested in not rocking the boat than improving the process.

6 years later…

When I started at SlickEdit, I was introduced to a lot of firsts. I’m a Microsoft programmer [ducks behind cube wall]. I’ve been programming with Microsoft’s APIs, toolkits, libraries, IDEs, etc for a long time. When it comes to Microsoft technology, I’ve done a lot, and it’s a world that I feel completely at home in.

My first assignment here was to test SlickEdit on AIX, having never used SlickEdit before and with virtually no UNIX background. I tried my best to learn my way around, but I never shook that feeling of being hopelessly lost. To make things worse, everyone else was using it at the Jedi Knight level. All of my creature comforts were gone during this testing cycle. As an experienced programmer, it’s humbling and flat out embarrassing to have to ask questions like, “How do I install this program?”, “Where is my personal directory?” and “How do I build with GCC?”

When I got to work on Tools, and got back to Visual Studio and Windows, I felt like I was back home. I knew where everything was; I knew which step was the creaky step, I knew how to use all the buttons on the TV remote control, I was completely familiar with my surroundings. This isn’t at all to say that Visual Studio is better than SlickEdit, because in a lot of ways, it’s not. The same could be said about Windows vs. UNIX or Linux.

After so many years, I’ve become a creature of habit, and I recognize that. Not because the task of learning a new OS or code editor is too difficult, but because I really hate the feeling of being lost. Even worse is thinking about the wasted hours learning to do the same thing I could do in my comfort space in five minutes. Most horrible of all is just feeling stupid about not knowing how to do the simplest things.

After all this time, I feel like I’ve gained a little perspective from my old manager’s side of the fence. “Don’t take away their console interface… they don’t want to learn, they just want to get their job done,” was what he was really trying to say. Starting from square one and leaving your areas of proficiency behind is scary. I’m always happy to learn new things, but it’s always nice to come back home. Now I see his point of view.

I often get involved in a similar debate about SlickEdit–not about whether it is a floor wax or dessert topping–but whether it is an editor or an Integrated Development Environment (IDE). To answer this we need to examine a brief history of programming and the differences between editors and IDEs.

A Brief History of Programming
The first evidence we have of man as programmer lies in the cave paintings in France. Some would have you believe that these are depictions recording daily prehistoric life. If you look more closely it becomes clear that these are really the first known examples of a written program.

The programming language is symbolic with a confusing syntax. What, today, we would write simply as:

requires many more figures in this primitive programming language. Of course, there were no computers back then, so all programs had to be hand executed. This could explain why most of the programs were about hunting and dancing. These early cave programs were written with bits of charcoal and pigments made from plant extracts. Editing tools were utterly lacking.

Another prominent example of early programming is seen in Egypt during the reign of the pharaohs. While some hieroglyphs may, indeed, be a form of writing, some we now know were early programs. This is particularly true of the large obelisks carved by the Egyptians. These were intended to be inserted into a large, obelisk-shaped reader. Unfortunately, no examples of these early peripherals still exist. As with many stone computers, they were disassembled and reconfigured into items more practical in those times, such as homes, restaurants, and parking garages.

The Egyptians’ programming language, called Osiris (later replaced by Osiris++), uses several abstract symbols that are combined to represent a larger set of programming concepts. In fact, the Egyptians were the first to introduce the concept of the variable, as seen in this example:

Though no interpreters from that time still exists, it’s largely believed that this statement translates into:

Again, the Egyptians had little in the way of editing tools. Programs were typically written with a hammer and chisel, making undo a very time consuming operation. They did, however, introduce the earliest use of whiteboards in the form of clay tablets, which allowed them to prototype code in a more forgiving form.

There isn’t time for a comprehensive history of programming, so we’ll have to skip over the early Greek and Roman programmers, who used Scroll 1.0 to write their programs, and frontier programmers in the early American west, who whittled their programs out of wood. We’ll skip past systems where you toggled programs into the front panel in binary and those using paper tape or punch cards.

The modern era of programming began in 19-mumble-mumble with the advent of the teletype. With these systems you had access to your full program and could readily extend and modify it. Editing was done a line at a time, so these editors were called “line editors”. You would print a range of lines, then type a command to insert or alter a line.

Teletypes were just an evolutionary bridge to the console, early CRT systems that displayed your code electronically. With consoles, the first visual editors were created. These editors displayed a page of code and allowed you to move a cursor within the file. Editing could be done simply by positioning the cursor and inserting or overwriting characters.

Contemporary editors share many characteristics with these early editors. They have added features like syntax highlighting, Graphical User Interfaces, window management, and a host of other features, but the process of writing code is fundamentally the same. Typically, these editors are file-oriented. You open a file, make changes, and save the file. All other activities are performed by programs or utilities launched from a command line or shell.

Integrated Development Environments group the related development activities into a single…well…integrated development environment. This is generally considered to be more convenient because it allows previously separate utilities to interact.

An IDE generally has 4 main components:

1. An editor—something providing the heretofore described ability to write code.
2. A project/build system—something that knows about the set of files in your project and allows you to launch a build on these files.
3. A compiler or interpreter—that allows you to build and execute your program.
4. A debugger—that allows you to step through your code and examine values.

Typically, an IDE will also provide a number of code/object browsers, integration with source control tools, and other utilities related to programming.

Interaction between the editor and the other components in the IDE provides key points of efficiency not available using standalone editors:

• The project/build system provides the knowledge of the available files and symbols in the program. Using this information you can browse to open files and use powerful completions while typing. This saves keystrokes, prevents wasted time looking up functions and methods, and reduces the number of compile errors.
• Integration with the compiler allows an IDE to launch a build and gather the results of the build. Programmers can quickly step through the errors and navigate to the source code for that error. With a standalone editor, you must manually open files and execute an operation to go to the specified line.
• Integration with the debugger allows you to set breakpoints from within the editor and view the code in the editor as you step through the code. Though similar capabilities are available in standalone debuggers, the code will be displayed differently, often without or with different color coding (sometimes called syntax highlighting). Once you are used to reading code in color, any alternate presentation slows your comprehension.

Different Strokes for Different Folks?
So, obviously, the IDE has completely supplanted the visual editor, right? No, for a number of reasons some users still prefer to use editors rather than IDEs. Emacs and vi (and their descendents) are the two most common examples of these.

One reason some people prefer a standalone editor is that IDEs tend to be very GUI-oriented, providing graphical mechanisms to launch operations. Standalone editors tend to be command-oriented, providing comprehensive key bindings to initiate operations. Using commands and key bindings is a big boost to programming efficiency, compared to the time lost grabbing the mouse and selecting things.

The editors in IDEs are often less powerful than the standalone editors. When all you do is write an editor, you can focus on the kind of power programmer operations that really improve programming efficiency. Developers of IDEs have to split their time between the editor and all of the other elements in the environment.

The choice of platform also makes a difference. Use of standalone editors is far more common on UNIX and Linux systems than on MS Windows or the Apple Macintosh. UNIX and Linux users are typically more comfortable writing scripts to automate builds and process results. They see the OS as the integrated environment.

Even with these reasons, users of standalone editors are missing out on those key points of efficiency that come with an IDE. That’s why the descendents of standalone editors, like Vim and GNU Emacs, have been adding more of those capabilities.

So What the Heck is SlickEdit?
SlickEdit looks and works like an IDE, but we call ourselves an editor. This is because we don’t include a compiler or a debugger with SlickEdit. It’s also because we place our emphasis on the editor. SlickEdit is a command-oriented, keyboard-centric editor. In fact, SlickEdit began as a powerful visual editor that grew to include the most essential IDE capabilities.

Though we don’t include a compiler and a debugger(iii), we work with commonly available compilers and debuggers. If you have installed the GNU C/C++ tool chain, a Java JDK, or Microsoft Visual Studio, then SlickEdit works like an IDE, providing the key integrations described previously. SlickEdit detects the presence of these tools and interacts with them inside the SlickEdit environment(ii).

So, is SlickEdit a great editor that works like an IDE, or is it an IDE with a great editor? Like the Shimmer product in the SNL skit, SlickEdit is both.

————————————————————-
i: http://snltranscripts.jt.org/75/75ishimmer.phtml
ii: SlickEdit launches the Visual Studio debugger in a separate window.
iii: SlickEdit does include a copy of GDB to insure compatibility.

Managing Builds

Schema URL Mappings
 

We’ve been using CruiseControl.NET and NAnt for nightly builds of our products. Both technologies use an XML file format. SlickEdit’s XML features include Auto-completion of tags and attributes, gleaned from the definitions in XSD schemas. Visual Studio also has an excellent XML editing experience, but SlickEdit allows you to customize what specific XSD schemas are used for a particular XML namespace declaration. CruiseControl.NET does not distribute an “official” schema for their namespace, mostly because the CruiseControl syntax is extensible with a plug-in architecture. By using Microsoft’s XML tools I was able to take my existing CruiseControl project files and generate a starter schema. SlickEdit’s URL Mappings allow me to then use that custom schema for document validation and auto-completion.

In an effort to reduce redundant code and reduce the size of the NAnt source files, many common properties and tasks used by multiple projects have been broken out into a series of include files. However, locating a property or task that is defined in an external file usually requires a multi-file search.

Regex Evaluator

By using the SlickEdit Regex Evaluator I was able to craft a regular expression to search for task and property definitions. Once the expression was ready, I created a macro in Slick-C (SlickEdit’s C-like macro language)(snippet) to search for the word at the cursor in the current NAnt build file and any included build files. Now I have instant search across multiple files when the definition of a property or target eludes me.

Building Installers with WIX (Windows Installer XML)
WIX is an open-source toolkit from Microsoft for building Windows Installer .msi files. It too uses an XML file format. There are tools available in Wix for getting your project started and compiling your list of files to be installed, but authoring an installer still requires quite a bit of hand-editing the XML source. I use SlickEdit’s Aliases feature to provide completion of code snippets for commonly used Wix XML constructs. Aliases go well beyond simple insertion of prewritten code. You can configure an alias to format and auto-indent the new text, set the initial editing position, and prompt for replacement parameters.

Defining Aliases

All of the code for the installer is placed in a custom SlickEdit project. A custom project allows you to create as many organizational folders as you need, optionally organized by physical directories or file extensions. The real power in SlickEdit projects is the ability to define custom build steps to call external tools. Since this project invokes quite a few NAnt build targets, I customized the build menu by adding new build tools to the project. These allow me to invoke NAnt to execute the build targets and display the output in the build window.

Dabbling in PHP and MySQL, with a Side of PowerShell
A year or so ago, I worked on a side project to develop a content management website using PHP and MySQL. The application had to work with Internet Explorer, Firefox, and Safari browsers. Using SlickEdit allowed me to create a single project to organize the code and work with the Subversion repository located on a remote Linux hosting account. And I was able to edit the code on both a Windows XP tablet PC and my MacBook as the custom project format is identical on Windows and *Nix platforms. Customizing the project’s build commands allowed me to add shortcuts for opening pages in multiple browsers, execute MySQL scripts one the database, and transfer files via FTP to my remote hosting account.

PowerShell Syntax

SlickEdit supports dozens of languages out of the box, and has the ability to quickly add your own user-defined highlighting schemes or modify existing ones. I found that the default listing of SQL keywords didn’t include some of the MySQL keywords, but they were easy enough to add via the Color Coding options dialog.

For the past year or so I’ve been using PowerShell in place of cmd.exe, and steadily building a library of scripts to automate routine tasks. But it just didn’t seem right that such a neat shell language should have to be edited without any syntax highlighting. With SlickEdit, this was easily solved. To set up color coding for PowerShell, all I had to do was create a new language definition, specify the comment format, and add a list of keywords.

No Code Left Behind
These examples only begin to scratch the surface of the features available in SlickEdit. Your code or build process doesn’t have to be a second-class citizen just because it doesn’t fit neatly into Visual Studio. For all those times you have to “just edit it in notepad” or “run this tool from the commandline”, think of how SlickEdit could save you time and hassle.

Download Free Trial

You can download a free trial of Slickedit 2007 here: SlickEdit Trial

So, what do sports fans do during this down time. If they are desperate, they watch tennis, really desperate, maybe try to get into watching a soccer game. But, if you are exceedingly desperate, you invent a new tournament sport.

The Single Elimination Font Championship

It’s hard to pick a really good programming font. There are a lot of fonts out there, just google for “programming font” and you will find a lot of really great fonts, and a lot of really weird fonts. But how do you pick the best font?

Here is my grudge about font selection dialogs. They work in one of two ways:

1. They will only show you one font at a time.
2. They display the list of fonts in the font itself.This seems like a nice visual solution, except that it makes it impossible to
   decipher the font name of a symbol font or foreign language font.

Finding a good programming font seems to involve a lot of trial and error. Some fonts look great in the font dialog, but do not look very good in practice. Sometimes it is hard to read vertical spacing from the font dialog. Sometimes, the plain font looks great, but it’s italic or bold variant is horrid, and you do not notice that until you are using the font in your editor.

In this article, I am going to outline a design for a new paradigm for font selection that overcomes some of these issues, including the problem with there being no sports on TV.

Picking the contestants

The first step is to select a set of candidate fonts. This is where you use a traditional font dialog, with one modification to the font list: checkboxes so you can pick which fonts will participate in the tournament.

The Playoff’s

Once you have a set of contestants, you begin the playoffs. The fonts are assigned randomly into a single-elimination bracket. A slightly more thorough variation of the system could use double-elimination brackets, but I don’t believe it’s really necessary.

The font contests are head-to-head. You are shown a big dialog with both fonts, their names, a size selector, and six samples side-by-side:

1. The plain font with programmer-friendly sample text:

   1 2 3

   == Line before == Aa_Bb_Cc = (l1 + O0); == Line after ==

2. The font in bold with the same text.
3. The font in italic with the same text.
4. The font in bold and italic with the same text.
5. The font in underline with the same text.
6. An editor control with your color scheme displaying code
   in a language of your choice where you can paste in your
   own text to see.

Then you select the font that you like better, and move on to the next contest. The fundamental principal is that while it may be hard to select a favorite font from a list of 100 fonts, most programmers can look at two fonts and pick one that they like better than the other.

The brackets are played out until you reach the championship round and select one favorite programming font, which you will then have the opportunity to assign the champion as your default source window font in SlickEdit. Playing out the brackets with a single-elimination tournament requires (N -1) contests where N is the number of candidate fonts participating in the tournament. Even with a huge field of 50 fonts, you could finish in 15 minutes, and you would know that the font you are using is a champion. Which will leave you plenty of time to catch that spelling bee later on ESPN2.

Conclusion

“It’s so crazy, it just might work.”

This is merely a design sketch for a font tournament system. It’s not a feature that is being developed or even in the works, just an idea. If some industrious SlickEdit user wanted to exercise his/her Slick-C skills, it would be quite easy to implement, and would be a really great user-contributed batch macro.

I mean, what else are you going to do with your time? It’s not like there’s any sports on TV.

I don’t know if it is a uniquely human trait or a natural consequence of any intelligent beings that develop language. Some say that dolphins have sophisticated communication abilities. If so, they could be swimming around discussing all kinds of topics,

“Isn’t the water chilly, today, George?”
“Actually, I think it’s gotten a bit warmer due to that global warming I keep hearing about.”

Or they could be swimming around arguing, the way humans do.

“Herring.”
“No way! Anchovies!”
“I’m telling you, herring is way better than anchovies.”

This trait is particularly common among programmers. Classic arguments include big endian versus little endian, indexing arrays beginning with 1 or 0, and which language is best. While the other debates have subsided a bit, the argument over which language is best seems to have heated up.

I’ve read a lot of articles lately where the author compares two languages in an effort to show why his favorite is superior. Often, these articles make it clear that only an intoxicated moron would use the language he so clearly shows to be inferior to his. Often, this superiority is established by showing features lacking in the one language. Sometimes they try to demonstrate superiority by accusing a language of being verbose and showing how the same thing can be achieved in fewer characters in the other language.

Fundamental Theorem of Programming Languages
In order to analyze programming languages, you first need to understand why they exist. I offer my fundamental theorem of programming languages: Programming languages exist to make computer programs understandable to humans.

Modern computers execute machine instructions that are represented in binary. Programming languages were created to overcome limitations in human cognitive abilities. It’s just plain hard for us to look at 1s and 0s and make sense of a program. So we created abstractions that make it easier for us to express and understand the actions we want the computer to perform.

Any comparison of languages should examine the abstractions they provide to facilitate human understanding of the program.

Second Theorem of Programming Languages
The second theorem is closely related to the first: If programmers do not understand a piece of code, they will either break it or rewrite it.

More important than how quickly you could write the code is how quickly someone else will be able to understand it later. This principle can be called “obviousness”.

An example of this principle occurs in languages that don’t require variables to be declared before they are used:

How can I tell if this line of code is correct? Maybe this line was supposed to use “param” instead of “parm”. I can only tell this by reading the rest of the code. The compiler (if this was a compiled language) would be no help, since this is perfectly legal. This minor typo, which is easily caught in some languages, can be very difficult to find in others.

You might be surprised how many times you have to look at the code to even notice this problem, even when you know the problem is in this unit. A common problem in proofreading is that you see what you expect to see not what you actually sea (sic).

Third Theorem of Programming Languages
My third theorem goes as follows: No single programming language is equally suited to all programming tasks.

If all languages contained the exact same set of abstractions, they would differ only in minor syntactic ways. Then all languages would be equally applicable to all programming tasks, and we could analyze languages merely by comparing the effectiveness of the syntax chosen.

Things to consider when choosing the language to use:

• Normal stuff—performance, compatibility with existing code or libraries, …
• Size of the team—I can staff a large project with competent Java programmers much more easily than with similarly capable C++ programmers (measured in how likely the code performs the intended action without unintended problems).
• Size of the code—a short script allows you to forgo many of the heavy-handed mechanisms or processes that are helpful in larger programs. Some say that the usefulness of Perl decreases rapidly as the number lines in the code increases.
• Longevity of the code—if the code is to be used and maintained for a long period of time, coding in a language that clearly expresses intent is much more important. See the Second Theorem of Programming Languages.
• Domain—what does the program do? Certainly I would make a different choice in languages if I need to write a real-time operating system kernel versus writing a GUI-oriented web application.

Tool Support
One last thing to consider when choosing a language is tool support. The right editor can often make a bigger difference in your productivity than the syntax of the language. Can an editor readily provide completions for the language you are considering? If you are typing every character in your program, you aren’t nearly as productive as someone who makes effective use of completions. How easy is the language to parse? Can a program readily provide type analysis? This will determine how easily tools can be developed to support the language.

At SlickEdit, we’re in the business of helping you write code. I speak from experience when I say that some languages seem to go out of their way to make it hard on us. Whether you’re picking the language for your next project or designing a new language, please keep these principles in mind.

–Scott Westfall

I was excited to start using SlickEdit, because I’d heard about all the fancy features during the interview process. I’d browsed through the forums and seen the kind of devotion the product had garnered. I’d seen some of the SlickTeam coding like mad men, windows opening and closing, text disappearing and appearing somewhere else, all faster than I could follow, all without my favorite crutch, the mouse. But when I actually sat down to start coding my first tasks, it seemed I had two left hands. Using SlickEdit for the first time feels a bit like driving an airplane on the highway. Sure, you can get to work with all the rest of the sedans and minivans, but the whole time, you get the feeling that there’s something more that you’re just not sure how to access. So you try a button, maybe you read the manual a little bit, and slowly you pick up new tricks. All the while you have to force yourself to use those tricks before they fade away into the abyss of That Thing You Learned That One Time.

My coworkers, the SlickTeam, were all too willing to show me the power of their product. The slogan of my first week could have been “Well, that’s one way to do it,” as each person chimed in favorite features and tools and explained why those were better than the ones the previous person had outlined. People outside the coding world would never understand the passion that can be evoked about things like aliases, brace styles, and syntax expansion. At the end of it all, I would have been glad to remember one tip from each person. Still, it’s keep your head down, use the command line, code code code, don’t touch that mouse. It’s harder to learn to fly an airplane than drive a car, but I daresay it’s worth the effort once you’re in the air.

I’m catching on, surely, but too slowly for my tastes. Every time I reach for my old friend the mouse, I feel like I’ve somehow let someone down. Every time I navigate through the extensive codebase that is SlickEdit, I know that there is probably a much easier way to find whatever it is I’m looking for, because this is a product built by impatient programmers. But I will figure it out. And someday I will regard some new member of the SlickTeam as he takes the long way around, then I’ll interrupt and say, “Well, that’s one way to do it.”

While no editor can offer the exact same set of capabilities as another, SlickEdit provides more of the powerful editing features that CodeWright users are accustomed to than any other editor…and some that CodeWright users never had before, like Comment Wrapping, Backup History, and the Regular Expression Evaluator.
 
No programmer relishes the thought of switching editors. After using an editor for years, the key sequences and operations become second nature. To ease this migration, SlickEdit offers a CodeWright emulation that uses the same key bindings for common operations and provides default behaviors familiar to CodeWright users. This makes you productive right away on SlickEdit.

A PDF of the CodeWright emulation is available at http://www.slickedit.com/codewright.

SlickEdit also provides a utility that converts CodeWright workspaces and projects into SlickEdit workspaces and projects. Each CodeWright .psp file is converted to a corresponding SlickEdit .vpw file. Likewise, the CodeWright .pjt files are converted to SlickEdit .vpj files. While this utility doesn’t convert all commands or options, it does save a lot of time setting up the project structure in SlickEdit. The CodeWright project converter is implemented as a Slick-C macro file.

To download it, go to http://www.slickedit.com/codewright.

Follow these instructions to load the file:
1. Save the file to any directory.
2. Open SlickEdit.
3. Select Help > Product Updates > Load Hot Fix.
4. Navigate to the saved zip file, select it, and click OK.

Once loaded, you run the converter by selecting Project > Open Other Project > Convert CodeWright Project. Or you can run it from the SlickEdit command line. Press F9 (in the CodeWright emulation) to bring up the SlickEdit command line. Type: convert_cw_project –oThen press Enter. The ‘o’ option tells the converter to open the newly converted workspace. CodeWright users, you have a new home!

Visit www.slickedit.com/2007 to download a free trial today!

Customers evaluating SlickEdit^® sometimes note that there are cheaper editors out there and that $300 seems like a lot to pay for an editor. Yes, you can pay less for an editor—some are actually free. But focusing on price is missing the most important aspect of an editor: how it can make you more productive.

Rather than asking whether there is a cheaper editor available, you should ask whether there is a better editor available. The right tool will always deliver more than enough time savings to pay for itself. If not, you should look for another tool.

Professional Tools
As a programmer, the editor is the main tool of your trade. The editor is to the programmer what the tennis racquet is to the tennis player or golf clubs to the golfer. Do you think Tiger Woods cares whether there is a cheaper set of golf clubs out there? OK, Tiger can afford any clubs he wants, but professional players are sure to have the equipment they need to be competitive. Should you do any less?

No other tool contributes more to your productivity and effectiveness than your editor. So by choosing a less capable editor, you are really choosing to make yourself less capable, to get less done in a given measure of time. If you’re being paid by the hour, that may be fine. Maybe you have one of those jobs where you can just code as you like and turn things in when they are ready to go. The rest of us, who are on a salary with challenging milestones, know that we are the ones who have to put in the late nights to get things done on time. In that situation, you want the tool that will help you get more done, faster.Not all editors are alike. If they were, you could make a decision solely on the basis of price. The right editor will not only increase your productivity, it will reduce your frustration. Much of what’s involved in programming is tedious, busy work. SlickEdit allows you to focus on what the code should do while it handles many of the boring, clerical tasks.

As a professional programmer, you have an investment in the knowledge and skills you have built. This knowledge is not limited to just the programming languages and techniques you use. It includes your mastery of programming tools. As the primary tool of your trade, you should have a special command of your editor.

Return on Investment
Only you can calculate a true return on investment for your work patterns. However, it’s easy to show that you don’t have to save much time to quickly make up for a $300 purchase. Assume an annual salary of $60,000, which is a conservative value for the average salary paid to programmers in the USA. Assuming a normal work year of 236 days and a normal work day of 8 hours, you have to save 1.6 minutes per day [i] to pay for SlickEdit in the first year of purchase.Here are some of the ways SlickEdit can help you save 1.6 minutes per day:

• It takes 30 seconds for Eclipse™ or Microsoft^® Visual Studio^® to open on my machine. The same project in SlickEdit opens in a second or two. So SlickEdit can save you that much time if you open your environment at least 3 times per day.
• Our tagging engine allows you to instantly jump from a symbol to its definition with a single keystroke (Ctrl+Dot). In most editors, you have to either know the file and where it is stored or search for it. Then you have to scroll down or search for the function name. This process can easily take 30 seconds to a minute. So a couple of quick navigations per day will pay for SlickEdit. By the way, we also have a Symbol View that will preview the definition of the current symbol without having to open the file!
• We have many features that cut down on the number of characters you have to type, like Syntax Expansion, which automatically completes block statements like if and for. Surround With quickly wraps the selected lines in a block statement. In a normal coding session, these will easily save you a couple minutes.
• Code Templates automate the process of creating new classes or patterns. Powerful substitutions are run when a template is instantiated, easily saving you a minute or two on a simple class and several minutes on multi-file templates.
• DIFFzilla^®, our dynamic differencing tool allows you to compare files and edit them in the diff view, providing many of the same editing capabilities in our editor window. This saves wasted time re-running a diff after making changes.

For a more complete list of the features we think will save you time and frustration, check out our Cool Features list on our website: http://www.slickedit.com/content/view/353/217, containing feature descriptions and demos showing those features in action.

But My Company Won’t Buy Me an Editor
OK, you’re convinced. You want to buy a new editor. You’ve talked to your boss about the benefits and the added productivity, but your company won’t buy it for you. Well then, buy it yourself.You’re thinking, “Not only does this guy want me to spend $300 on an editor, but he wants me to buy it with my own money!” That’s right. As a professional programmer, your skill with your editor is as important as any other knowledge you possess. Purchasing an editor that makes you more capable is an investment in your career that can pay off in better reviews, higher salaries, and bonuses. Hey! Maybe we’re giving away money after all.

——————————————————————————– [1] Calculation for minutes per day savings:

Overhead is the cost for benefits, equipment, training, facilities, and management. We use a conservative figure of 50% for overhead. Many websites say overhead is as high as 100% to 200%.This calculation assumes an annual salary of $60,000 per year, which is a conservative median salary for programmers in the USA. It assumes 236 work days per year based on 104 weekend days, 10 company holidays, 10 vacation days, and 5 sick days. It assumes a normal 8 hour work day, 480 minutes per day.

* Color coding
* Syntax expansion
* Code navigation features
* List-members and function parameter information
* Comment and function documentation extraction
* Syntax-driven auto-indentation
* Macro recording and playback
* Code snippets and other shortcuts
* Integrated project build support
* Multiple file and window support

Color Coding
Color coding is a language specific feature which allows the editor to display comments, keywords, strings, numbers, and other lexical elements using specific foreground and background colors as well as potentially using bold or italic fonts.

Argument
“I don’t need my editor to look like Walt Disney lost his lunch.” — How do you find your car in a parking lot? Do you look at every car until you find your 1998 Camry with velvet blue interior, or do you look for a red sedan with a “My border collie is smarter than your honor student” bumper sticker. Color stands out; it helps you find things. You have a color monitor, why waste the potential?

Benefits
Color coding helps you distinguish comments from code. If that were all it did, that would be a great win, but it can do so much more. Color coding also helps you see immediately when you have mistyped a keyword, or if you have accidentally used a keyword as an identifier, or failed to terminate a string. This saves you many compile and edit cycles and lets you focus on what’s important.

Investment
There is very little investment to this feature; if anything, you may find yourself un-training your eyes because you do not have to read as much syntax to see comments vs. strings vs. code.

Syntax Expansion
This feature completes statements for you so you only have to type the leading keyword such as “if” or “while” and the editor will insert the rest of the code for that statement in accordance with your brace style and indentation preferences.

Argument
“I’ve been coding for years; I type these statements without even thinking.” — This is true for many seasoned programmers, but the real question is why?

Benefits
For novice programmers, syntax expansion can save them time trying to remember how a particular statement is written. This is especially true for statement heavy languages such as COBOL. For all programmers, syntax expansion helps enforce coding consistency; it will always use your brace style and your indention preferences.

Investment
In fact, the investment to start using syntax expansion is just a matter of un-training your fingers to type the whole statement. Very quickly, you will get used to just typing “while” and then being ready to put in the loop condition.

Syntax driven auto-indentation
Auto-indentation will position your cursor at the expected indentation level when you split or open a new line so that you can start typing code immediately. A good implementation of auto-indentation will respect your tab preferences and either insert real tabs, spaces, or position the cursor on a virtual column without inserting unnecessary space. A very good implementation will handle more than just simple block scopes: it will also handle continuation indents, parameter lists, initialization lists, and splitting comments.

Argument
“I am very particular about indentation; I don’t trust the editor to do it for me.” — This is the sort of feature that must be configured to match your preferences. Once you configure it correctly, the editor will do the right thing more than 90% of the time. If it doesn’t, you are probably using the wrong editor, or in the worst case, can turn the feature off.

Benefits
Auto-indentation will save you time for every line of code you write. Furthermore, it will improve the consistency of your code.

Investment
This feature requires no time to learn, but you may have to un-train your fingers to not lean on the space key every time after you hit enter.

Code navigation
A good implementation of code navigation turns your code into a hypertext. For any symbol in your code, you can jump to it’s declaration or definition in one keystroke. You can jump back to where you were in another keystroke.

Argument
“I don’t need this; I’ve memorized where everything is.” — That’s very impressive; let me know how that works out when you inherit a half-million lines of code you have never seen before.

Benefits
A really good code navigation system makes file boundaries irrelevant, which make it possible for you to focus on the code, not what files the code is stored in. A good implementation does not just use the symbol’s name, but finds the symbol’s declaration or definition using the same language specific scoping rules that your compiler uses. A better implementation can also find all references to a symbol. An awesome implementation recognizes that when you navigate to a symbol and then pop back, it can close the file in order not to pollute your working set of open files.

Investment
In terms of keyboard shortcuts, you need to learn three things: (a) the key to jump to the symbol under the cursor, (b) the key to see all references to the symbol under the cursor, and (c) the key to jump back. If you have not been using code navigation, you are probably finding symbols by manually opening files and poking around, or using grep or another multi-file search to find symbols. In terms of work habits, you may have to train yourself that there is an easier way to do things and use it.

List members and function parameter information
List members (referred to as Intellisense™ by Microsoft) will display a list of class members in the class when you type a member access operator such as “.” or “->” in C++. You can then pick one of the items from the list and the editor will insert it, or you can continue typing the name of the symbol and the list will be filtered down to include only symbols that match what you have typed.

Function parameter information is typically activated when you type the open parenthesis for a function call and will display the prototype for the function being called and highlight the current argument.

Argument
“Those things will just get in my way.” — A well designed implementation of list members and function parameter information will not get in your way. List members is typically displayed below the current line, left aligned to the cursor position. Function parameter information is typically displayed below the current line, aligned with the function name. The windows typically have minimal borders and are shrunk down to the minimal size to display the required information. A good implementation works hard to stay out of your way when coding.

Benefits
If you do not have list members, you will need to be very good at remembering the names of the members of the classes and structures that you use. Suppose you need to convert a STL string to a character pointer. You may remember that it is done using the “c_str()” method. You may have an STL reference manual on your desk and can spend five minutes looking it up. If you have list members, you type “.” and then scan through the list and see that “c_str()” returns “const char*” and remember that is the conversion function.

Likewise, function parameter information brings vital information to you when you need it. Suppose you need to call the standard C library function strncpy(), but you can not remember the order of the arguments. You could look it up in your C book, check MSDN or the man page. That’s fine if you have five minutes to burn. If you have parameter information, the prototype is displayed for you: “char* strncpy(char *, const char *, size_t)”, and you can see immediately that the first argument is the destination (by virtue of being char*), and the second argument is the source string, and the third argument is the max number of chars to copy.

Investment
Typically, these features are invoked automatically when you type open parenthesis or member access operators. You will also want to learn two keyboard shortcuts: one to bring up list members manually and one to bring up function help manually. This will be extremely valuable to you when you are editing established code.

Comment and documentation extraction
Comment and documentation extraction pulls documentation comments from your source code and displays them in conjunction with list members and function parameter information. Really good implementations of this feature will format JavaDoc and XMLdoc comments for you, and highlight function parameter documentation when displaying function parameter information.

Argument
“What will I do with all these Java reference manuals?” — Build a giant pyramid in your cubical and declare yourself a Java deity.

Benefits
If your editor does not have this feature then when you need to see the documentation for a function, you either need to look it up in a reference manual, or jump to that function, read it, remember it, and then jump back to where you were working. Having this feature is like having a really good research assistant who brings exactly what you need directly to you exactly when you need it.

Another nice side-effect of having this feature is that it genuinely encourages you and your whole team to write better documentation comments in your code because you will be seeing them and using them on a regular basis.

Investment
This feature is typically completely automated.

Macro recording and playback
This facility allows you to record a sequence of keystrokes and/or editor commands and then play them back later.

Argument
“You’re hurting my head!” — No, your head will be fine, and your fingers will also appreciate the break once you master this feature.

Benefits
Sometimes you need to make a bunch of very similar changes to code. Macro recording allows you to do it once and repeat the macro instead of tediously doing the same thing over and over again. More powerful editors allow you not only to record macros, but to name them and save them for later. Some even more powerful editors allows you to record not just one, but a suite of macros that you can repeat with a single keystroke.

Investment
There are, at a minimum, two keyboard shortcuts you need to learn: one to toggle macro recording on and off, and one to repeat the last recorded macro.

Code snippets and other shortcuts
This feature allows you to define chunks of text that can be expanded using a keyboard shortcut.

Argument
“I just copy and paste when I need to create idiomatic code.” — The problem with this technique is that, first, it is slow and tedious. Second, it requires you to remember where you can find an example to copy. Third, when you copy and paste chunks of code, you might be copying and pasting chunks of code with errors in it.

Benefits
This feature helps you build a library of snippets of idiomatic code that you can expand at the touch of a key. To add further power, most editors support parameterized code snippets so you can plug in different variable names, constant values, etc.

In addition, some editors also let you define global shortcuts and use them nearly anywhere in the editor, including the open file dialog. Why type “/usr/include/sys/” or fiddle around with the mouse to navigate to that directory if you could just have an alias named “sys”, expand it, and continue from there?

Investment
You need to learn how to create and customize a snippet in your editor, and you need to learn one keyboard shortcut for expanding snippets.

Integrated project build support
This feature allows you to invoke a compile or a project build from your editor, and correlate the compilation errors with source code.

Argument
“We have a custom build system and we can not change it.” — In most cases, you do not have to change your build environment; you just have to be able to tell your editor to use your existing build command to build the project.

Benefits
The first benefit is that you will not have to leave your editor to start a build. You can associate the project build with a keyboard shortcut, such as Control-M (for make). You no longer have to remember the build commands for different, disparate projects. Last, and definitely not least, you can navigate directly to the compilation errors with a single keystroke instead of manually locating the offending file, opening it, jumping to the line number, and then repeating that process for every error.

Investment
You will need to learn the project system of your new editor; how to create a project, how to specify your build command. You will also need to learn the keyboard shortcut for navigating to the next build error.

Multiple file and window support
This is really two facilities. One is the ability to open more than one file at a time in your editor and rapidly switch between them. The other is to be able to open multiple windows so that you can look at different files or different parts of the same file at the same time.

In particular, I address this issue for the programmers out there who are still using text mode vi on Unix or notepad on Windows. Noting those exceptions, almost all other modern editors have these capabilities to varying extents. Some support multiple files and windows, but force you to use the mouse to switch buffers or switch windows. Some editors have a tabbed view for quickly seeing what files you have open and modified. Some editors have support for buffer management, so if you navigate to a file and then pop back (see Code navigation, above) the file is automatically closed, keeping your working set of files small and tidy.

Argument
“Too much clutter” — Some people like to keep things simple, so viewing just one file at a time is great for them, they don’t need side-by-side windows all the time. But, for those times when you absolutely need it, this is a feature that is well worth having available.

Benefits
Modern projects are large and encompass many source files, sometimes tens of thousands. You can seldom get a complete understanding of a system looking at just one file at a time. Being able to switch between files with a single keyboard shortcut is more efficient than starting a new editor to view another file. If you have unsaved changes to a file and need to look at another file, what do you do if your editor does not support multiple files?

Investment
You need to learn a few keyboard shortcuts: (a) to open a file; (b) to cycle through your open files; (c) to split windows horizontally and vertically; (d) to cycle through your open windows; and (e) minimizing and maximizing windows. The first two will get you up and running so that you can maintain a working set of open files. The last three will help you move to the next level.

Conclusion
It’s natural to resist change. Learning a new editor requires an investment of time and a change of work habits. You will seldom regain your investment in the timeframe of your first project with a new editor. But the time you will save in the long run will quickly eclipse the small amount of time you invest. Perhaps you feel that you are extremely proficient with your current editor, maybe even working at power programmer level. This may trick you into thinking that you are already working at peak productivity and will not benefit from a better programmer’s editor. The truth is exactly the opposite, you will benefit even more. Your tools are your foundation. Think of this analogy. No matter how proficient you are at riding a bicycle; you can go further faster on a motorcycle.

The features outlined in this article are things that I have grown to view as essential for writing code proficiently. It can be hard to appreciate exactly how much they help you until you seriously set down to work with these tools in your hands. After which, I can assure you that you will ask yourself how you ever managed to work without them.

Borland^® no Longer Engaging in New Development of CodeWright^®

CodeWright Emulation PDF
No programmer relishes the thought of switching editors. After using an editor for years, the key sequences and operations become second nature. To ease this migration, SlickEdit offers a CodeWright emulation that uses the same key bindings for common operations and provides default behaviors familiar to CodeWright users. This makes you productive right away on SlickEdit. A PDF to the supported CodeWright emulations can be viewed here.

CodeWright Project Support
SlickEdit also provides a utility that converts CodeWright workspaces and projects into SlickEdit workspaces and projects. Each CodeWright .psp file is converted to a corresponding SlickEdit .vpw file. Likewise, the CodeWright .pjt files are converted to SlickEdit .vpj files. While this utility doesn’t convert all commands or options, it does save a lot of time setting up the project structure in SlickEdit. From the SlickEdit  menu select Project > Open Other Workspace > Convert CodeWright Workspace.

Why SlickEdit

Speed: Type fewer characters and make fewer errors using syntax expansion, completions, aliases, and code templates.

Power: Create and manage large workspaces and projects. Edit files up to 2 GB in size.  

Flexibility: Code in over 40 languages on 8 platforms. Configure SlickEdit to match your coding style. Choose from 13 editor emulations.

SlickEdit Product Page: http://www.slickedit.com/content/view/73/60/

SlickEdit Cool Features Demos: http://www.slickedit.com/content/view/353/217

Click here to download a free trial of SlickEdit