I love Vim and Textmate

If you follow me you’ll notice that I’ve been playing with Vim lately. For almost a year now I’ve been a TextMate fan but something about Vim just called to me. Maybe it was the feeling that knowing Vim increased my geek cred just like terminal hackery does.

Vim and TextMate sitting in a tree
Vim and TextMate sitting in a tree

Why Vim

Really anyone doing any type of coding should be fairly comfortable in Vim (if you’re not I know a post on Vim). Vim is on any Unix system so it’s on all the servers you’re putting client sites on. If you have SSH access to your server Vim is way faster than FTP trickery.

Vim’s Killer Features (yeah I mean good things)

The feature I miss the most from Vim (when I’m coding in TexMate) is the modal editing. Just by hitting escape I’m moving the cursor around. Then start looking at using ‘W’ and ‘B’ to move whole words and you’re flying around the file so fast your hair will curl.

NERDTree is another pretty dang awesome Vim feature. Yeah I know it’s a Vim plugin but just go install it since it should just be included by default. NERDTress gives Vim a project browser like any other modern GUI text editor. You can move around with the normal Vim keys and open,close files lightening fast. It’s also super easy to jump to the parent folder and close it.

Vim’s Killer Features (as in your dead to me)

That dang copy/paste buffer. So you have a normal system wide copy/paste buffer that is pretty much the same no matter what operating system your on. Well Vim doesn’t care about that and it doesn’t use it. You see Vim has it’s own copy/past buffers that only work inside Vim (at least as far as I can determine) and the system ones don’t work. So that cool piece of code you put in your blog so you could reuse it, yeah it won’t paste into Vim, sorry.

No CMD+t to open a file in a project. While NERDTree rocks it’s still no CMD+t from TextMate. Sure PeepOpen adds that type of function to MacVim but not to Vim (and of course it couldn’t if you used it on a remote server).

TextMate go to file CMD+t
TextMate go to file CMD+t

Still Using TextMate

Really the only feature from Vim that I miss when using TextMate is the navigation of code with HJKL. There is a plugin that adds this to TextMate but I’ve found it a big buggy (lets just ignore the fact I’m on a hackintosh please). Well that’s not quite right I TextMate started having occasional issues getting stuck in the project drawer after I renamed a file, after I installed ViMate.

That’s All She Wrote

So I’m going to stick with both Vim and TextMate for now. Neither is quite what I’m looking for in a code editor. They both have awesome features and things that are a bit lacking.

At the very least if you’re working on code use Vim long enough that you’re comfortable in it. It just makes you a more well rounded coder. One day the time you spent in Vim will save your ass when you need to live edit some files on a live server that keeps dropping FTP but keeps and SSH connection. Trust me it saved my ass more than once.

Using Vim as a Text Editor

This is a guest post by Alan Bailward a long time advocate of Vim and friend.

Introduction

When Curtis first asked me to write about my programming workflow, I thought to myself “why would anyone care about a simple setup like I have?”, and told Curtis as such. Then a few days later I was showing him something or other at the FV.rb and I did something in Vi to a surprised “what was that”. A few more tips passed on, and a few more “how do I do that’s” and I realized it might be interesting, at least a little, to others.

The “elevator pitch” for what I do is “you make it pretty, I’ll make it work.” I work with a couple of small design companies who mock up a site and then hand it over to me, and I turn the static files into fully dynamic pages with working elements, create the admin backend to manage it, deal with making contact forms email out properly, and so on.

Most of my work is Perl, old school, none of this fancy “framework” or “php” stuff for me, nosiree! Actually this isn’t by choice, it’s due to it being legacy code, and the effort to re-write it all just isn’t worth it. Don’t cry for me though, now and then I do get a chance to work on some of the fancy-schmancy new stuff, and the setup is pretty much the same.

Working Setup

My set up is actually one of two setups. Some days I do my work on a MacBook Pro sitting on the couch, and some days it’s on an older desktop computer hooked up to a 21″ LCD downstairs in the office.

The hardware itself is pretty old, an AMD XP3000+ with 4G of RAM, an nVidia video card just capable of some of the 3D effects that modern operating systems provide, and basically all the best that 2002 had to offer. Too bad it’s 2010, but my Windows workstation has been on the receiving end of the last round of upgrades, as that’s my gaming box.

However, since my OS of choice for programming is Linux, the older hardware isn’t that big an issue. The version is 10.04, “Lucid Lynx”, which was installed when it came out. Other than a few extra bits of software installed (more on that in a second) and a tweak here and a poke there, it’s a pretty Plain Jane setup.

The day to day programming situation, or in my case, evening to evening, is sitting with with basically 3 windows open, one is a browser to run tests on the site, one is my actual programming window (sometimes several tabs of terminals, and one is tailing the log-files in the background so that I can see if anything strange is cropping up.

Tools

Main Vim Window
Main Vim Window

As you can see from the screenshot above, work is basically done in a couple of terminal windows and a browser. Code in the terminal window, reload the browser until things work. Rinse and repeat.

Of course, if that was it, that’d be the end of the article, and like I said earlier, I figured it would be.

However it seems that the tools involved in those two windows might be at least mildly interesting. Because I’ve been a Linux geek since 1994, most of the things I do are in the terminal, and therefor the tools I use are all terminal based.

While coding, I need tools that let me do three things really well:

  • See what is going on all the time
  • Quickly switch between different tools and documents
  • Make the code sing by being lightning fast inside my editor

My tool list consists of the following:

  • Vim – for all my editing needs
  • Screen – for keeping programs running and quickly switching terminals without switching windows
  • Tail – For watching log-files
  • Firefox or Chrome for a browser
  • The firebug web developer extension, along with the a few plugins (YSlow being the most prominent one)

So as you can see, not a lot there. I’ll go into a bit more detail on some of the apps and how they’re used.

Vim

Ah Vim, my old friend. I learned Vim from a huge gold book called Unix Unleashed back in my early days with Linux and Unix, sometime in the dark ages, before Kernel 1.0 (that’s 1995 for you kids out there). The reason that I prefer Vi over EMACS? Simple, the Vi chapter was first. Also I like my fingers where they were, and decided that the surgery needed to make that much use of the ctrl key wasn’t worth it compared to hitting ESC a bunch.

Note that I used Vim as well as Vi. Vi is the classic editor, available on pretty much any UNIX system since the 80’s, whereas Vim is the new and shiny version of Vi, with the same heritage, but with all the modern amenities such as syntax highlighting, tabs (in the GUI versions), multiple windows, ability to use the mouse, and so on. While I’m perfectly comfortable using “classic” Vi for most anything, for hardcore coding, Vim is the way I roll.

Vim Essentials

A working Vim Window
A working Vim Window

My Vim setup is fairly Plain Jane as well, but I do have a few settings and commands that I use all the time. Settings are stored in your “vimrc” file, which is a file named “.vimrc” and stored in your home directory. If you are working on a Unix based system (Linux, MacOS, etc) you can find this by editing “~/.vimrc”. Here’s a (very) abbreviated version of my .vimrc, with some comments:

" set syntax highlighting to work better with dark backgrounds, it defaults to 'light'
set bg=dark
" highlight found search terms
set hlsearch
" ignore case sensitivity in searches
set ignorecase
" searches for lowercase words match any case, mixed case searches turn on case sensitivity
set smartcase
" indent code properly
set smartindent
" similar setting to ensure tabs work properly
set smarttab
" if available, turn syntax highlighting on
syntax on
" switch quickly from window to window and maximize the window
map <C-J> <C-W>j<C-W>_
map <C-K> <C-W>k<C-W>_

A word of note here; despite having used Vi for 10+ years of coding, my knowledge of it is restricted mostly to the functionality that I use on a daily basis. I’d be remiss to not mention the excellent VimCasts podcast for a deep, yet beginner friendly look at some advanced functionality in Vim, and learning to love your .vimrc file.

Some of these settings should be wrapped with if/then/else’s, but just using these settings will give you the start of a much nicer experience, and you can copy and paste them into your ~/.vimrc file safely. Of course, to have an efficient workflow you need to know some commands.

As I said, I use the text version of Vim, not the GUI version. The GUI version allows you to have proper tabs, use a mouse, and fancy stuff like that, but that means you take your fingers off the keyboard, and if you take the fingers off the keyboard, you slow down, so I try to keep my fingers on the home row as much as possible. Vim’s history is in the console only dark ages of computing, so it’s well suited to this.

Here are a few “special” keystrokes that you might not know, assuming that you are familiar with Vi’s modal editing, and inserting and removing text:

ctrl-w ctrl-s

or

ESC :split

or

ESC :split <some other filename>

The first two commands will simply split the current editing window in two, allowing you to view two parts of the same file simultaneously. The last command will split the window in two and load the filename you specify into the second pane.

ctrl-w ctrl-v

or

ESC :vsplit

or

ESC :vsplit <some other filename>

Same as the above, except the window is split horizontally. Note that you can split a window as many times as you want and in combinations of “split” and “vsplit”.

ctrl-w ctrl-w

This will let you jump from window to window. If you have the mappings I use in my .vimrc you can also use ctrl-j and ctrl-k to jump between windows, while maximizing the current one. If you want finer adjustment of your window sizes, you use ctrl-w + and ctrl-w – to resize the windows.

If you’re not happy with the order of your split windows, you just need to run:

ctrl-w R

(Note the “R” needs to be capitalized). This will reverse the order of the windows.

Vim is a huge program, so this stuff is only scratching the surface, but it is a step up in terms of helping you to code from the defaults.

Screen

Screen is one of the two or three UNIX tools I’d choose to spend the rest of my life on a desert island with. That doesn’t sound too weird does it? Screen is described as a “screen manager with VT100/ANSI terminal emulation”. Not all that descriptive. The description from the man page goes something like this:

Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC terminal and, in addition, several control functions from the ISO 6429 (ECMA 48, ANSI X3.64) ISO 2022 standards (e.g. insert/delete line and support for multiple character sets). There is scroll-back history buffer for each virtual terminal and a copy-and-paste mechanism that allows moving text regions between windows.

What is means is that you can, with a single login, in a single window, control and switch between multiple windows. If you’re really old school you might have used DESQView back in the day, and this might be familiar. No one here is that old though.

Regardless, the details are unimportant compared to how it actually helps you do your job. The workflow goes something like this for me.

  1. Start a terminal window and ssh to the web server
  2. On the server, change to the correct working directory, more on this in a moment
  3. Run screen
  4. In the screen program start editing the source code that I’ll be working on today
  5. Create another screen window with the shortcut key “ctrl-a c” (IE: Hit the key combo “ctrl-a” to get screen’s attention, and then ‘c’ to create a new window) and edit another source code file in that window (note that here a “window” is actually another terminal session, displayed in the same “shell” as you are already)
  6. Open another screen window with ctrl-a c and start up the mysql command line
  7. Switch back to the first window by hitting ctrl-a <space>

Screen has only a few keyboard shortcuts you need to know to get a lot of use out of it

  • ctrl-a c – Create a new window
  • ctrl-a <space> – switch to the next window
  • ctrl-a ctrl-a – toggle between this window and the next
  • ctrl-a <ESC> <arrow keys> – scroll back in the terminal scroll-back (your terminal scroll-back won’t work)
  • ctrl-a d – Disconnect this screen session from the window, but leave it running

There are lots more, but these are the core. The last one is the most interesting though, what this does is allow you to do is to stop coding, disconnect your session, go to work, to Starbucks, whatever, boot up an ssh session to the same machine, and then start session with “screen -r” and have your session back exactly where it was, with the editor just where you left it, your programs running, etc. Extra bonus: If you forget to disconnect your session when you left home, you can run “screen -rd” to start up and disconnect the running session and reconnect to it. You can even have multiple screen sessions running at once.

How does this help? Well, it means I can have all my editing environment set up the way I like it and never shut it down, while being able to get at your currently used workspace from whatever computer you’re at, as long as you can get to the server as the same user.

Browser and Add-ons

My Firefox working setup
My Firefox working setup

I don’t have anything overly special in the browser, a few plugins that help with any HTML, CSS or JavaScript debugging I may be tasked to do. These will be pretty familiar to anyone who has done much web development work using Firefox:

  • Firebug for performance tuning and checking things like post variables and some minimal CSS/Javascript/HTML tweaking
  • YSlow for doing performance testing
  • (Sometimes) the Web Developer Toolbar for some of it’s nifty CSS/HTML revealing
  • Live HTTP Headers is also used periodically

Conclusion

So that’s about it…a very, very long way of saying that I use a web browser and a 20 year old text editor in a terminal window to do all my work 🙂

The Great Windows Code Editor Hunt: Sublime

This is the fourth instalment in our search for a solid Windows Code Editor. You can find the other parts listed at the end of the post. While this editor wasn’t in my first list of editors to review it was suggested in the comments and I’m glad it was.

The Good

Sublime has awesome keyboard navigation. Want to divide the project window vertically and show two files, how about horizontally and show two files? Neither of those items is hard just hover over the buttons from the navigation menu and the keyboard commands will show.

Not something that I was originally looking for but the mini-map provided by Sublime is a great little feature. The min-map shows up on the left hand side of the file you’re working on and allows you to see exactly where in the document you are located. This is especially useful in a big file as a quick visual reference. I found that I’d turn it on of the file extended outside of the coding window and back off when it wasn’t needed.

Sublime Text Editor Mini-Map
Sublime Text Editor Mini-Map

While Sublime doesn’t have a project drawer it does have an awesome project file search. In fact I’ve pretty much decided that if the project file search works like this I don’t really need a project drawer to view my project files. Navigating files with a mouse removes your hands from the keyboard and slows down your coding process. So yeah I’m totally willing to give up the project drawer for something more efficient.

Sublime Text Editor Find in Project
Sublime Text Editor Find in Project

The Bad

As I’ve stated above Sublime has a ton of options but unfortunately the way to access those options is a bit kludgy. While the other code editors I’ve reviewed so far have nice GUI interfaces for working with the options Sublime just opens up an XML file with the options labelled. The labels are pretty descriptive but the reality is that it’s not a GUI interface which makes it more difficult to work with.

Sublime Options
Sublime Options

Sublime also makes a project file for the project. Again it’s something I wish I didn’t have to deal with but it seems that you can’t really have a project without some file that references and remembers where all the assets are stored. Not huge points against the tool but still something I could live without.

Conclusion

So far Sublime seems to be the best option I’ve found for Windows. It’s quick clean and pretty well-organized. I can see that people just really getting into coding could be a bit overwhelmed by the options provided but for someone willing to put the bit of effort in need to decode the options this is a killer code editor for Windows.

In all honesty if I hadn’t talked about reviewing some of the other editors I think I’d just stick with Sublime. It’s got the right blend of features and the few draw backs aren’t anywhere big enough to make the tool unusable.

The Other Parts

The Great Windows Code Editor Hunt: InType

InType Logo
InType Logo
InType Logo

We’re now on the third code editor in our epic hunt for a great windows editor. If you’d like to catch up and see where we’ve been:

The Great Windows Code Editor Hunt: Part 1

Dreamweaver

Komodo Edit

Now it’s on to InType.

InType is still in Alpha and is similar to Textmate for OSX. In fact it’s so similar that it even imports Textmate bundles with a bit of conversion. I just started using Textmate on my OSX installation (switching from Coda for HAML, SASS, and LESS highlighting) and the two do bear a number of similarities.

The Good

InType starts up super fast which is a far cry from the other two editors (Dreamweaver, Komodo Edit) that I’ve looked at so far. Even while rendering video in Handbrake, InType started up with little lag and remained responsive during the entire time used.

A second point for InType is the amazing code completion. With all of the bundles available for InType you’re pretty sure to find the language and code completion you’re looking for. Sure it doesn’t have some of the popular web app languages like Ruby but you shouldn’t be doing ROR dev on a Windows box anyway.

image of the InType bundle list
image of the InType bundle list

InType is also very configurable. While it doesn’t have the wealth of options that Dreamweaver has you also don’t spend an hour looking for an option. Really the most important ones are at your finger tips in the main editor window. Need to change your indentation for HAML to two spaces…go ahead it’s at the bottom of the editor window.

Intpye preferences panel
Intpye preferences panel

That also brings me to another great feature of InType, visualization of your tabs and spaces. I haven’t had an editor that has done this before so when I opened my projects in InType I was greeted by a cacophony of tab and space styles. Ultimately it made more work for me as I went through and changed everything to be 4 spaces but it means I’ve got cleaner code instead of the soup of indentation styles I unknowingly had before.

The Bad

I know InType is still in Alpha and it does show sometimes. One issue that kept cropping up for me would appear when starting InType up, for some reason it would forget it’s location and open with a small window in the upper left corner of my monitor. Now I normally use two monitors and have the code editor open in the bottom right of my second monitor…so InType would jump across my entire desktop on occasion.

InType forgot where it should be
InType forgot where it should be

Another point against InType is the fact that it adds a project file to your project. Not a huge issue but yet another file to declare in my .gitignore file. I’d prefer that we didn’t add a project file but I can live with it.

The code completion of InType could also throw off some users. Sure it’s similar to how Textmate works but it’s also very different from the way Komodo Edit or Dreamweaver does it. Both Komodo Edit and Dreamweaver start hinting while you’re typing while InType waits till you hit tab before providing options to complete you’re typing. So when working in CSS you’ll need to type “background” then press tab, which will present you with all of the options for background. It even shows you the properties that background can take. Again it works but depending on where your experience lies you may find it odd.

Intype's code completion
Intype's code completion

Finally, and probably the biggest point against InType is the fact that it doesn’t have access to remote files. If you’re working with InType you’re working locally. I honestly do this anyway so it’s not a huge issue for me to fire up a FTP client or SSH into the server and transfer the needed files when I’m putting up a project for final client sign-off. It would be nice though to be able to connect to multiple servers out of a project like Dreamweaver does.

The Conclusion

While InType is a bit rough around a few edges overall it’s a pretty solid editor. It has all of the little features like easy theme management, code completion and the few draw backs are hardly show stoppers. At the end of the day InType is happy to just melt into the background and let you interact with your code.

The Great Windows Code Editor Hunt: Dreamweaver

Dreamweaver CS4 icon
Dreamweaver CS4 icon
Dreamweaver CS4 icon

This is the second post in The Great Windows Code Editor Hunt series. Today we’ll look at Dreamweaver as a code editor.

The Good

Dreamweaver has come a long way for coders since CS3. When I used the CS3 version it was barely tolerable as a code editor. I don’t remember why at this point but I do remember having to switch back to CS3 when the CS4 beta ran out and my employer at the time decided not to upgrade. I remember ranting for a few days about how the UI was crappy in CS3 and CS4 was way better.

Dreamweaver is highly configurable. Working in a language that requires a certain amount of tabs or spaces to work properly? Not a problem. Hop into the Preferences pane and under ‘code format’ adjust as you need. It doesn’t stop there though. Like your code hinting in a fashion other than default? Dreamweaver provides you with a few options and at least one should suit.

Dreamweaver CS4 preferences
Dreamweaver CS4 preferences

Another wonderful feature of Dreamweaver is the ability to connect to different servers on one project. I’ve used this feature a number of times to work on a WordPress theme locally then, with a simple dropdown, connect to my development server and upload the required files. When we’re ready to push to the client’s server simply open the drop down again and connect to the live environment and upload the files. A great thing they introduced in CS4 with the Files panel is that it is now dockable or can sit free-floating on another monitor if you wish.

Dreamweaver CS4 file browser
Dreamweaver CS4 file browser

The Bad

So what are the things that make Dreamweaver not my code editor of choice? It starts with the WYSIWYG editor. While it’s possible to enter full code view and not see the code editor somehow it always seems to sneak into view. I’ve never been able to stop the ‘Design View’ to disappear entirely. For some reason I was never able to track down some files would randomly open in the ‘Design View’ of Dreamweaver forcing me to go back to the top and click on the ‘Code View.’ I’ve just dug through the preferences panel again and don’t see any option that leads me to believe I can just shut down the design view permanently.

So one of my requirements was load time. Dreamweaver is a pig. I run Windows 7 on an AMD Athlon 2.6 with 8GB of RAM and a 1GB video card. It’s not a slow system but Dreamweaver seems to be the morning coffee hounds best friend as it takes forever to start-up. Yeah go get a coffee. Even on the 24″ iMac I used at my last job Dreamweaver was a pig to get running. To my very unscientific observations, it didn’t seem to matter if it was a cold or warm start. The green dialogue that shows during startup might as well say “Go Get a Coffee there’s lots of time”.

Dreamweaver CS4 coffee load screen
Dreamweaver CS4 coffee load screen

Another beef with Dreamweaver is the amount of crap files it introduces into your projects. It seems that in every folder you end up with an extra folder called _notes and an extra file called dwsync.xml. Sure they’re not big but they also don’t matter to the client’s website and are thus bloat. I think these files have something to do with FTP syncing with the server but whatever they’re actuall purpose removing them from a project is yet another step to take before packaging files up to send to a client at the end of a project.

Themes in Dreamweaver are a pain. For all the configuration options available there is no real way to quickly switch away from the original eye searing white theme. I’ve got big thanks for That Web Guy since he has great instructions on how to change the white theme out on Dreamweaver. It requires a change to an actual application file in Dreamweaver which is stupid but I suppose it’s not all that hard. I’m still astonished that Dreamweaver doesn’t have an easy way to switch between multiple colour themes though. Seems like every other code editor out there, even those in alpha have it as a default feature.

While Dreamweaver has a great project browser it really doesn’t do a good job or any job of tracking your files since the last upload. I can’t tell Dreamweaver to only pushed changed files. Sure I can sync the files but then we’re waiting while it figures out what that sync it. I see no real reason why it can’t mark the file state at last file upload and then only upload the files that have changed. We’ve got lots of other application bloat why not something useful.

A final point I’d like to put against Dreamweaver is the file type support. I work with Github more and more which means I need to edit README files. Dreamweaver has no clue what to do with the file nor does it offer me a good way to tell it what to do.

Conclusion

Really the only reason that Dreamweaver was included in the review is that it comes with many version of the CS4 suite of software. I really don’t think it would be a contender if it wasn’t included with other software I need to do my job (Photoshop and Illustrator). I certainly wouldn’t be forking out $400 bucks for Dreamweaver after working with it during the trial.

We can also add as a point against Dreamweaver the general distaste seen for it by prospective employers. Sure I wrote a while back that Dreamweaver is a fine tool but that doesn’t change the fact that you see daily job ads that say don’t apply if you use Dreamweaver.

Ultimately I’m not using Dreamweaver because it’s slow to open, doesn’t recognize a number of common files I’m working with, doesn’t integrate with Git at all, and I just can’t get that stupid ‘Design View’ to go away. Maybe minor things all but it amounts up to a code editor that just doesn’t suit my daily coding habits.

The Great Windows Code Editor Hunt

code editor article imag
code editor article imag
code editor article imag

I’m a web designer/programmer so I spend a good portion of a day in a code editor (at least if it’s a good day). I’m pretty particular about what code editor I use and what features it needs so I’m on a hunt for a great code editor for Windows. My plan is to use a code editor for at least 2 weeks to really get a handle on exactly how it works and to get as familiar as possible with all of the shortcuts.

The Requirements

So lets start by figuring out exactly what I’m looking for. I’m not going to list the normal things like syntax highlighting that are just required to even get into my list for testing.

  1. Code Completion of Some Fashion: I need code completion of some fashion. Whether that’s adding the end tag automagically upon completion of the beginning tag or if it’s hinting at the next tag to close. I’m not picky really on which way it works. Extra point for tab style tag and block code completion.
  2. Project Browser: The code editor needs to have a project browser (Sorry VI) even if it’s not included out of the box there needs to be a plugin to make it work.
  3. Dark Theme: It’s a personal preference but I need a darker theme to look at all day. My eyes hurt if I get stuck looking at something super white all day. Light greys or browns all work just can’t be white. And you need to make it easy to switch the theme with some template of some fashion. I’m not opposed to having to build a template if none exists already but it better be easy to do.
  4. Lite Weight: I don’t want to wait forever to open a file. I willing to wait on the first cold start of the day but after that you better be quick.
  5. Good Looking: If I have to look at and work with you all day you better be pretty, well pretty enough. I’ve seen a few editors that just look really freaking ugly. I’ll admit I’m a bit vain and I require a UI that looks good and works.

Nice to Have

  1. Snippet Management and Completion: I end up working across 3 different OS’s so while I like snippets built-in I find they’re never on the system I need them on. I’d like it but it’s not a deal breaker.
  2. No Project File: I’d love not to have a .whatever project file added to projects but if the rest of the application rocks then I’ll deal with adding it to my .gitignore file.
  3. Editing of Live Files: My workflow has me building all my sites locally and doing all my testing for browsers there. I don’t need to edit live files on a server often so I don’t have much call for publish on save but if you have it I’ll give you a point.
  4. Cross-platform: I end of doing a bit of work on Windows, Mac, and Linux so I’d love something I can learn and use across all platforms as my main development platform.
  5. Spell Checking: I write all my blog posts in a text editor so spell checking would be great but not a need. I use After the Deadline on by blog before posts go out and will continue to do so even if the editor has spell checking.

The Contenders

So I’ve got some contenders already. Some I’ve used and some I’m planning to try.

  1. Dreamweaver: I get it with CS4 Design Premium so I figure I’ll go over why I’m not using it (yeah that was a spoiler). Read Review
  2. Komodo Edit: Not the paid IDE but the free Komodo Edit. It appeals because it’s cross-platform and free is a good price. Read Review
  3. gedit: It’s the right price and on my two main platforms for development (Windows, Linux) so it’s in.
  4. InType: Heard lots about how it’s like Textmate for Windows. Textmate is the cat’s ass according to some programmers I know so I figured I’d be up for trying it. Read Review
  5. E Text Editor: Another Textmate for Windows I hear. I actually tried it a few months back and for some reason that escapes me right now I have no idea why I’m not using it still. So if I can get it running again on the trial I’ll review it.
  6. Notepad++: It’s a staple of any programmers “I’ve tried it” stable so now I’ll try to be its lover for a bit.
  7. PSPad: I’ve been told that real programmers on Windows are using Notepadd++ or PSPad so it’s in.
  8. Sublime: Suggested below and reviewed.

What’s Missing

Am I missing something in my list? Is there a code editor that you just love and hasn’t cropped up on my radar? Let me know. I don’t promise to use it but I promise to at least visit the site and see if it could be a contender.