Code editors are like toilet paper: Seriously … how can you possibly improve on it? You type some code, you hit compile, you debug. I have this attitude lots of times, opting for VIM with simple syntax highlight over something like Eclipse, with syntax highlight, code completion, incremental compilation, code folding, and refactoring support. But, when I’m full into a project, whipping out Java code, I’m really glad I’m using Eclipse, where these features often help me code faster, with fewer errors.
So, I was thinking of a few features I wish I had. If you have any or examples of some you like, please send them in. Include a screenshot if you can.
Scope Spotlight
The first feature I was thinking about was something I’m calling scope focus. The basic idea is that the you use background colors to identify the current scope level. If your background is white, then the current scope your cursor is in would be full on white, as the you move away from that scope the background color would gradually darken. The darkness levels would be a function of the innermost scope in the current file. Funny, enough, however, XCode has this feature. I would not have seen it if I had not recently started doing iPhone development.
Here’s a screen shot:
- Is the scope my cursor is currently in. You don’t see the cursor, but it’s there.
- Is the enclosing scope, and it’s darker than the inner
- The next enclosing scope is darker still
- The gutter shows the scopes again, with code folding widgets. If you notice the gutter above the “4″ you’ll see a slightly darker rectangle, that indicates that there is another scope at that location.
This is really useful and I could imagine that for a language like Python where indentation is used to indicate scope. For example, if I keep to the 80 columns convention, then I sometimes have to add carriage returns for long lines and this sometimes adds a little indentation. If the scope is long it can get tricky trying to figure out where the next scope is. This is specially true if it’s midnight and I’m having a hard time seeing anyway. This would also be really useful when hand-editing XML.
Back when I was in my early 20s, 10 point was my choice for editing code. As I get older, I’ve had to crank up the size of my type. So anything that helps with vision as a programmer gets older is welcome.
I’d like to see this in Eclipse and TextMate. Maybe it’s there already, and, if not, someone can probably write a plugin or a bundle. One problem with XCode is that I have to mouse over the gutter to get this effect. Maybe there’s a way to turn it on? It would be ideal to turn it off with one keystroke, too, so that I can navigate the file without seeing the effect, then turn it back on again as I focus on a piece.
This feature makes me think of the full-page editing modes in Scrivener and other word editing programs. I’d like to try full-screen for coding, but I tend to have a few resources open at the same time so maybe it wouldn’t really work. I also navigate a few files at the same time, so project resource navigation would have to be there.
Current Line Zoom
Make the type of the current line larger. Here’s a TextMate screenshot I altered to show this feature:
This is another vision/text related wish. Many editors have a feature to change the background of the current line you’re in. I don’t know if this was its initial purpose but I use it to find out where I am in the code after I come back from a meeting. Nowadays cursors are small slim lines and not chunky blinking blocks, which often makes it hard to see where you last placed it after an interruption.
Notice I added another gutter, which would show perspective lines to indicate that the 183 applies to the line. I could have resized the line number too. I couldn’t decide which method would work better.
One thing I noticed while modifying the screenshot is that the feature would have to keep the left-alignment, so a simple “expand” won’t do, since the text to the left of the “private” keyword would push the keyword to the right, and then you lose the formatting often helps us determine scope.
I also thought of decreasing the zoom from the current line to adjacent lines until the zoom reaches the default type size. This is not shown in the screenshot above. The idea would be that adjacent lines would get gradually smaller.
Breathing Space Auto Scroll
This other feature is related to scrolling. Let’s say you start with a blank file. As you code, your cursor goes lower and lower towards the bottom of the window or view. When you get to the bottom, your cursor stays there and any new line you enter is at the bottom of the view. If the editor supports it, I use a key combination to scroll the view up, so that the cursor is a little more than halfway up the visible area. Then I keep coding until I get to the bottom and repeat the process.
Sometimes I end up having to add a bunch of carriage returns at the end of the file so that I can get enough “breathing room” to let me scroll the last line to the middle of the view. This sucks.
Therefore, I’d like to see the following feature:
- As you type, if you are getting near the bottom of the page, scroll the page so that the cursor doesn’t go all the way to the bottom of the view.
- Allow the user to scroll a little past the end of the last visible character so that the last line of the file is not at the bottom of the view.
This could be implemented by adding a “virtual” view over the actual view. The top and bottom of the virtual view would be maybe a third of the way (or some configurable distance) from the top and bottom of the actual view.
I think I’ve seen this feature in Emacs.
Have a look at the Natural Programming Project if you’re interested in these sorts of ideas.
I’d like to be able to actually test if these improve quality of code and speed of coding. Or maybe it doesn’t negatively or positively affect qualitative measures of coding but it does make for qualitative differences in the experience of coding. In, other words, maybe it makes your coding a little more fun and a little more enjoyable.