Code Editors

When I was first hired at SlickEdit, I remember going out to lunch with one of my fellow developers (Dennis, for those of you who are familiar with our language support guru) and having a conversation about how cool it was what some people get to accomplish every day, developing software. I think Dennis sensed that I might have been less than enamored with some of my daily tasks at SlickEdit, in terms of their positive impact in my world, and he was nice enough to express his personal feelings on the subject. When some people are writing code that is run on robots collecting data on Mars, and I am trying to implement some possibly-obscure set of commands for our Vim emulation, it is easy to look out the window and wonder what crazy-awesome project there is that I could be coding. Well as usual, Dennis hit the nail on the head and enlightened me that any feature I am working on for our editor could be saving hundreds of programmers valuable minutes (hours?) in their day. This, in turn, enables them to churn out more code, be much more productive, and lets us be at least a small part of all their great accomplishments. All was well in the jungle.

I recently came across a great local story about software making a huge difference in the lives of many children in our area. Just up the road in Wake Forest, NC, Melissa Matthews recently won the “Ikea Life Improvement Sabbatical Contest”. The award was a $100,000 grant to continue work on a project which will improve the lives of others in their community. Melissa is the mother of a child with down syndrome, and is well aware of the incredible work of software developers who are creating apps for special needs children. She is working with the Frankie Lemmon School right here in Raleigh, NC, to enhance their use of technology in furthering the education and development of their students.

If you check out the website born from this project/grant at http://frankielemmonschool.org/technologies, you can read all about the efforts of Melissa and the Frankie Lemmon school. One iPad app currently in use (DAF Assistant) helps students who have speech impediments by relaying delayed auditory feedback to them as they speak. It’s been well studied that this technique can make a big difference in their development. In true SlickEdit fashion, the app is very customizable and has received great ratings in the iTunes store :) . There is a list of all apps for the iPhone and iPad being researched and used at http://www.kcdsg.org/files/content/24470331-iPhone-and-iPod-touch-Apps-for-Special-Education.pdf.

Of course, short of contacting any of these developers directly, I have no way of knowing that our editor was a part of the development of these pieces of software…but it sure is possible. At any rate, it’s always nice to hear about fellow coders who are working on special projects and making a difference. Maybe they are hardcore Vim users who just wish they had a nice graphical interface to organize their projects, while still being able to use their familiar Vim key bindings…

Whenever we’re putting together marketing materials, advertising copy, checklists of features to demo at trade shows, etc, a common start of the conversation is “What are the top features of SlickEdit”. Feature lists are all well and good, but just because we think a feature makes a Top Ten list doesn’t mean it resonates with every user. And features are usually spoken of in broad brush strokes, like “Version Control Integration” or “Configurable Keyboard Emulations”. But what really makes your editor an indispensable tool is the collection of small features and tricks that you use every day. And there is no Top Ten list that covers this, as everyone’s list is different.

We did a quick poll around the office to gather up some of the features that we use all the time. And yes, everyone’s list was quite different. So in no particular order, here are a few of our favorite things in SlickEdit.

Italic bold below denotes a Slick-C command, like complete-next, which can be executed from the SlickEdit command line or bound to a keyboard shortcut.

complete-next and complete-prev
Bound to Ctrl+Shift+> and Ctrl+Shift+< in most emulations. This searches for prefix matches in your current document. Very handy for completing words when you’re working in plain text or in a file format where Context Tagging is not able to provide symbol matches, or when you want to pick up non-symbol matches, like words found inside comments.

where-is, what-is, and bind-to-key
For those of you who like to keep your hands on the keyboard as much as possible, you need this. Sure this information is available on the menus and in the Options dialog, but why mouse around? Entering where-is on the SlickEdit command line will allow you to enter a Slick-C command to see if there’s a keyboard shortcut defined for it, while what-is lets you see the command name for a shortcut, or check if it’s free. Use bind-to-key to define a shortcut for something that’s currently not bound to one.

Aliases with %\n
If we had to list which features of SlickEdit we feel are underutilized outside our office walls, Aliases would be at the top of every list. Aliases simply allow you to type a short sequence which will be expanded, which is great for frequently used boilerplate text. They can be defined globally or on a per-language basis. We do provide some aliases out-of-the-box, but the real power is in creating your own. Go to the Tools > Options dialog, and search for “Aliases” to see where you can define them.
A common usage is generating “Caveman Debugging” statements. Here’s a sample alias for C.

printf(" %\n: %\c \n");

The SlickEdit alias facility has several escape sequences, and %\n is the sequence for “current function name”, and %\c positions the cursor for editing after the text expansion is made.

toggle-comment
This feature originated as a macro written by one of our customers, which he shared on our community forums. It was so popular that we made it part of the product. It’s a great complement to comment-lines and comment-block.

Quick replacements from the command line
Doing a quick search and replace inside the current file is a snap using the c/old/new/ syntax on the command line. Even more power comes from using command modifiers after the trailing slash. For example, the ‘m’ modifier means ‘mark’ (our term for current selection), and ‘*’ means globally without confirmation prompting. So to change all instances of char to wchar_t in your current selection without a prompt, you would enter c/char/wchar_t/m* on the command line, and you’re done.

svc-diff-with-tip
This is a super-quick way to compare your current file with the most recent version in version control, bypassing the version control history dialog. This currently supports CVS, Subversion, and Git. And if you’re using Subversion, and not currently able to connect to the repository, svn-diff-with-base performs a comparison with the ‘clean’ copy from your most recent update.

svn-get-annotated-buffer and cvs-get-annotated-buffer
A wrapper around the “blame” command for CVS and Subversion. Warning: May be habit-forming.

list-buffers and project-load
These bring up the Files tool window. Stop right there! You’re about to skip past this one because the word “Files” is pretty plain, and “bring up the Files tool window” sounds pretty dull. Do yourself a favor and try them out, and perhaps set up keyboard bindings for them. list-buffers will show you a searchable list of all the files you currently have open, allowing you to quickly switch to one without having to search through file tabs. Handy if you tend to leave a lot of files open in the editor. If you have a project open, the Project and Workspace tabs of the Files window allow you to find any file and open it from there. Very helpful for large projects.

Vim cursor keys
I hesitated to include this one initially. It’s not specific to SlickEdit, of course, and is only one of the 15 keyboard emulations we define. But if you’re a vi/vim adherent, having a high fidelity vim emulation built into your IDE is a big deal. It allows you to get all the benefits of the tools and features built into the environment without having to rewire you brain when you actually need to edit code. If you’ve ever accidently typed a stray ‘j’, ‘h’, or ‘dd’ or into an instant messaging client, you know exactly what I mean.

What feature(s) is/are highest on your list?

Many developers work with source code which resides in files with “non-standard” extensions. By a standard extension, I am referring to something like .cpp or .java. By a non-standard extension, I am talking about .ryan, or .data. I will show you how to quickly and easily set up your SlickEdit Core editor in Eclipse to handle these files the way you want them handled.

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.

« Previous PageNext Page »