Text Editors for Windows Perl

A person’s editor is a sensitive topic, much like their religion and favorite sports team. Some of it makes sense, some of it is superstition, and you’re likely to get a finger in the eye if you try to take away their favorite editor. It’s not unheard of for people to quit jobs to go to one that lets them use the tools they like.

These applications fall into two major camps. There are the editors that are just editors, and then there are full Integrated Development Environments (IDE) that try to handle everything for you. Some people prefer to create their own environments. I prefer a tool that I can use for many things instead of a tool which limits me to a particular task. I learn fewer tools that way and things I learn in one domain help in another.

The perlfaq3 documentation lists several possibilities, but its list of out-of-date and largely untouched for over a decade. I know: I was responsible for most of the updates for the perlfaq for over a decade, and I ignored this stuff unless someone complained.

There are some things I find necessary for good work:

  • Must handle plain text
  • Should handle UTF-8, although you can scrape by with ASCII
  • Line numbering is very important
  • Tabs would be nice
  • Syntax highlighting helps a little
  • Jump to a function definition

Before you download any of these editors, be very wary of what you are actually downloading. Many of the advertisements and site features intentionally lead you to install other software. Sourceforge, once a tool for good, is particularly bad about distinguishing ads for trojans from the download links. It’s one of my biggest surprises coming to the world of Windows. I’ve messed up more than a couple of virtual machines through this. But, that’s why I use virtual machines with snapshots.

If you want the short story, I like either Notepad++ or Komodo Edit. I mostly judge editors based on how the line numbering looks. If the line numbers are there but recede toward the background, the developers probably did everything else that I like.

As I said, different people like different things. If you like something else, or want to help defend your choice, leave a comment or email me to give me more information.

Included editors


The MS-DOS program edit works from a Command Prompt command line. It’s a basic visual editor that might save your bacon if you have no other options.


Notepad is a plaintext editor application. You can type and perform simple editing, but that’s it. If you’re in a pinch it’s probably there for you.



Word is a word processing application. These sorts of applications differ from text editors because they hold hidden state in the file to remember formatting and structure within the document. Perl won’t know what to do with this stuff. WordPad can save as plaintext, but it’s too easy to save it incorrectly.


Free editors


This is the editor that I prefer at the moment. Notepad++ is my sort of editor. It’s light, has tabs, numbers its lines, and has the basic editing operations I need. It understands Perl syntax (and many other popular languages), which it colors and autocompletes. It even does block folding.


Komodo Edit

Komodo Edit is ActiveState’s free offering that breaks out the editor from the Komodo IDE. It understands most of the popular languages, but it takes a bit of tweaking to integrate with external programs.



ConTEXT is a free editor, but clicking on a download link brings up a sneaky PayPal page to make a donation. I don’t have a problem with shareware, but I don’t like these sorts of things popping up without warning. I bet, though, that the developer gets many more donations this way.



GNU emacs has pre-built distributions for Windows. Be sure to get the one that is not “barebin” unless you know what you are doing; that distribution doesn’t have the lisp files that the executables need to run. Emacs is one of the big armies in the editor wars. I think everyone should try it a little and understand it even though I don’t think they have to like it.

There are other binary distributions for emacs too.



Vim is a vi clone, or, “Vi iMproved”. It’s one of the Big Two editors in the land of unix, but it also has binaries for Windows and other systems.



Kephra is an editor written in Perl and WxWidgets, although it’s not targeted at only Perl development. Since it’s written with cross-platform components, it’s not limited to Windows. If you have to work on different platforms and want to use the same tool everywhere, this could be interesting to you.


Eclipse + EPIC

The Eclipse IDE is aimed mostly at Java and C++ developers, as well as other specialized sorts of information workers. The EPIC plugin adds functionality for Perl developers. You’re probable interested in these tools if you already use them for something outside of Perl and don’t want an additional tool. Eclipse needs Java, which you might not want to fool with.


Padre is an open-source editor written in Perl and WxWidgets.

Padre installs itself like any other Perl module, and that’s it’s major drawback. It’s bound to a particular Perl installation and anything you do to that installation, including updating modules. It comes as part of DWIM Perl, a variant of Strawberry, but it’s a shame that I need to install so much to get an editor.


The SciTE editor works both in Windows and X (so, it supports unix-like things and others), and there’s a pay version in the Mac App Store ($41.99).


Pay Editors

I have no problem paying for an editor (and I’ve been paying for BBEdit for years). Programmers are people who need to eat too. Some of these are listed in perlfaq3, which is why I list them here.

Sublime Text

Sublime Text is a cross-platform editor available for Windows, Mac OS X, and Linux. It’s in active development, has a trial version, and costs $70 for continued use. It has many attractive editing features and is highly configurable.



SlickEdit is a multi-platform development environment. There’s also a plugin that allows you to use SlickEdit from Eclipse.

It’s $299 for a single user license on Windows. There’s a 15 day free trial.


The full version is $244.50 + $7.50 shipping and handling. It’s $46.50 for the Multi-Edit Lite.


I’ve used UltraEdit for other projects (often short term things where I could get away with the trial version) and know some Windows programmers who like it. If I wanted to buy an editor, this would probably be the one to get.

The full version is $79.95, with a full-featured 30 day trial version.



Zeus has many features, but it has spread them out through menus and settings that I think would be confusing for people used to Windows. It’s $89.95 with a 14 day free trial.


Old Editors

I debated including this list, but finally settled on the idea that if you know they are out-of-date before you start your search for a new tool, I’ve saved you some time. I’ll leave some notes about what I find, but I’m not going to expand on them since they are dead ends. I include some of them because they are listed in other dated Perl resources.

Some of these come with an embedded Perl, which might be out-of-date as well. Indeed, any editor with “Perl” in the title is something that I suspect as a hold over from the dot-bomb days when the word “Perl” was a big draw.


Last updated in 2009. $109.90.


Free. Last updated in 2009.

Open Perl IDE

Last updated 2002.


$59. Last updated in 2008.


I think this editor is mostly dead, although there’s some text on the page that makes the dates stay current. It heavily references CGI programs and there’s not a mention of Windows after Windows 2000,


visiPerl+ had the curious feature of a variables pane so you could drag names into a document to make it easier to use the same name in each file. I’d rather see that with auto-complete, but even seeing the list might be useful.

There’s a 14-day trial version and the $59 full version. However, it hasn’t had a new release since 2001.

Windows command shells

Windows needs a better terminal program. If you’re using Perl, you’re going to have an easier time dealing with life at a command line—that’s where Perl came from and how it’s oriented. That’s also how you’re likely to deal with Perl once you leave Windows. I’m certainly going to have an easier time since I’ve been a shell guy for a long time.

I’m ignoring cygwin and that bash terminal that it provides, or . If I fell back to that, everything is easy because it’s almost like running unix. Instead, I want to stay as close to Windows as I can, at least for this project. That’s where I see the greatest need and the most opportunity—even if cygwin ends up being the best answer.

I also need to note that a command shell is different from a terminal emulator. The latter connects (e.g. telnet and ssh) to something else and lets the remote side do the work. This is also different from IDEs where I might run my Perl program inside the same application where I edit it. I’m only interested in command shells in this one.

There are some important features for me:

  • easy cut and paste
  • tabs for multiple sessions in the same window
  • some sort of history
  • resizable, wide windows (past 80 columns)

My philosophy of tools is that there is no universal right tool. Some people will be more productive in those some people can’t get any work done. Try several and pick the one that you like best, reserving your option to change tools when you feel like it.

Tell me what you like by leaving a comment.

Included out of the box

The included applications are bare bones and reflect the good ol’ days of 80 column terminals. I can make the windows narrower but not wider. The cut-and-paste features are inept, and none of them have tabs. I can run multiple instances of a command interpreter though.


Command.com is the old MS-DOS interpreter that suck around for the Windows 9x and Windows ME releases. I’m going to ignore it. If you’re still stuck on those systems, I’m sorry.

Command Prompt

The Command Prompt, also known as cmd.exe is the interpreter for Windows NT and Windows 2000 and later.

The clink adds bash-like features to Command Prompt. It comes out of the Lua community, but that’s okay.

The Command Prompt’s killer misfeature is it’s antiquated inability to handle Unicode properly. It limits the fonts you can use (see Raymond Chen’s Why are console windows limited to Lucida Console and raster fonts?). Your program might output the right things, but it you can’t see it in the console, what good is that console?



Powershell is a command interpreter on steroids. It’s a decent shell and it really shines when you want to do Windows-specific things since you can pipe objects between commands. It’s also a bit nicer than Command Prompt.

Powershell has a history mechanism so I can easily recall and replay commands, but I find it verbose and a bit klutzy since it’s built on top of .NET and is a consequence of that. I can get around with alias.

Powershell also suffers from the same Unicode problems as the Command Prompt, for the same reasons.


Third-party programs

Some third-party apps are fancier window dressing around the command interpreters that already exist, and some add features in addition to them. The applications that wrap the Command Prompt have all the same problems.


The ConEmu has tabs, each of which can run a different command shell. I can run a Command Prompt in one tab, Powershell in another, and some other shell in a third. It provides the window but the command interpreters stay the same.

Selecting text is a problem, so I don’t like this one either.




Console 2 has tabs, but they are all Command Prompts. It’s copy feature requires that I hold down the shift key to make a selection. That works, but it’s really annoying and sends this one to the bottom the list for me.



PowerCMD has tabs, but it also lets me see more than one tab at a time and in a multitude of configurations.



FireCMD has a free 30-day trial. It has a command interpreter, but includes a terminal emulator, text editor, and many more things. It aims to add a “Unix-like environment”, but it doesn’t quite get there. It’s its own shell that looks like a little of both.



Take Command

Take Command has a free 30 day trial. It extends the Command Prompt command set and works with its own IDE.


If you like bash, then Win-bash might be what you want. Some people mistake this for Unix, but how the operating system works and how you interact with it are different things. I can use bash commands (not “unix commands”!). I find it annoying in the slightly odd ways where it’s not exactly like bash. Like the Command Prompt, it limits the available fonts, making it unsuitable for development with Unicode. It also can’t make wide windows.


Dealing with code pages

A code page is the mapping of values to characters, and something you have to think about if you’re dealing with some Windows things. The Command Prompt and filenames, deal with particular code pages. There’s an input code page, which handles what our programs get, and there’s the output code page, which interprets our output to display or store it.

Different distributions of Windows use different default code pages. Code Page 437, for instance, was the original IBM PC hardware code page. Some distributions of Windows are localized, so they have a code page appropriate for that language. That’s called the OEM Code Page (or just OEMCP).

You can check your code page with the chcp command:

C:> chcp
Active code page: 437

There are some ANSI Code Pages (ACP), officially called Windows Code Pages since they aren’t actually standards. You might have run into CP-1252, which handles English and some Western languages.

You can change the code page inside the Perl program. The Win32::Console modules allows you to do that:

# change_output_cp.pl
use Win32::Console;

my $CONSOLE = Win32::Console->new;
$CONSOLE->OutputCP( $ARGV[0] );

There’s an additional wrinkle. When I change the code page from within Perl, I modify the console and it stays that way after my program finishes. That’s different from the Unix model where child processes can’t change things above them.

Z:\> chcp
Active code page: 437

Z:\> perl change_output_cp.pl 65001

Z:\> chcp
Active code page: 65001

If you are fooling around with code pages, you probably want to reset the code page to whatever it was when you started.

# restore_output_cp.pl
use Win32::Console;

my $CONSOLE = Win32::Console->new;
my $original = $CONSOLE->OutputCP;
$CONSOLE->OutputCP( $ARGV[0] );


$CONSOLE->OutputCP( $original );

Another curious feature is that I can output to more than one code page in a single program and see the right things in Command Prompt:

# show_code_pages.pl

use v5.10;

use Win32::Console;
my $CONSOLE = Win32::Console->new;

say "Input code page is ", $CONSOLE->InputCP();
say "Output code page starts as ", 
	my $original = $CONSOLE->OutputCP();

foreach my $arg ( @ARGV ) {
	$CONSOLE->OutputCP( $arg ) or do {
		warn "Could not change to CP $arg\n$!\n$^E";

	say "\nOutput code page is now ",  $CONSOLE->OutputCP();
	foreach my $point ( 0 .. 255 ) {
		my $char = chr( $point );
		$char = '.' if( $char =~ /\s/ or $point eq 8 );
		print $char, ' ';
		print "\n" unless ( $point + 1 ) % 16

$CONSOLE->OutputCP( $original );

Even though I output the same characters for each code page, the console displays them differently according to the current code page.

The common advice to display UTF-8 is to change to CP-65001, but that doesn’t quite work here. The ASCII range works, but the 8-bit characters show up as boxes:

I have to bring in some of Perl’s Unicode features. The -C switch turns on some of the things I need. The -CS encodes the standard file handles as UTF-8. When I add that, I get the right characters, but some weirdness in how the lines show up. For the second half of the output, the end of the previous line is repeated.

I suspect this is a bug in the Window’s console handling of UTF-8, and that CP-65001 is part of the issue. It’s not just Command Prompt that has this issue; WinBash shows the same behavior. Various people have made vague references to issues with CP-65001 but never got down to the actual issue, which I think is very deep in the architecture. Part of this is the console’s inability to use a proper font.

If I turn on autoflushed buffers with $|++, the line wrapping problem disappears, but another problem shows up. Each code number above 127 takes up two spaces:

Powershell (and Powershell ISE) is even more deficient in displaying these characters. WinBash doesn’t do any better.

Further reading

Windows Perl distributions

Which Perl distributions are people using? I know the major ones, but are there some that I’ve left out? I’m not looking for every distribution that’s ever existed, but the ones that have at least a little bit of traction.

I’m also curious how people chose which distribution to use. Was it convenience, a particular library that came with the distribution, a supporting application (such as PerlApp), or something else?

Distribution Latest Perl Version
ActivePerl v5.18
Strawberry Perl v5.18
DWIM Perl v5.14
Citrus Perl v5.16
IndigoPerl v5.10

What’s your favorite Windows Perl trick?

What particular things do you keep doing in Perl to work with Windows? It doesn’t really have to be your favorite, but I want your stories about how you make Perl, which started as a Unix tool, work in a non-unix environment.

I’m particularly interested in what you do with filenames through the Win32 API, and how you interact with programs through OLE (or whatever).

Leave a comment here, send me email, or whatever you like. I’ll come up with some way to select the best one and send you a free copy of the new Mastering Perl once I get them.

Strawberry Perl

Strawberry Perl is an enhanced distribution of Perl. It includes everything that comes with the Standard Distribution and the extras it needs to install CPAN modules—including those that need to be compiled. Strawberry includes GCC, dmake, and other tools to make this possible. It also includes extra sets of modules.

from David on flickr https://flic.kr/p/bBBym4

The Strawberry project grew out of the Vanilla Perl project started by Adam Kennedy when, in January 2006, he offered a vertical meter of beer for a package that:

  • Uses a native installer of Perl for Windows, for at least Windows NT or Windows 2000 and later.
  • Can install modules directly from CPAN.
  • Includes a compiler that can handle XS modules.
  • Is freely redistributable.

By summer, Vanilla Perl was born. Vanilla Perl was the bare bones, but it was meant to be. It was Strawberry Perl that would build on top of that to add extra tools and modules so that a person could download, install, and start working right away. It was targeted at people familiar with Perl but not Windows, and it tried to be as unix-like as possible with a strong reliance on the command line. The Strawberry Project came out with Perl 5.10.0 in January 2008, and in April 2008 added Perl 5.8.8. Since then, Strawberry Perl has mostly kept up with the standard Perl releases, although there is usually a lag as the maintainers prepare a new version.

The initial Strawberry installations went in c:\strawberry and it had to stay there. By October 2008, the project had figured out how to put Strawberry somewhere other than the main disk. The first “portable” version would install on the D:\ drive (the optical drive, usually). The January 2009 release added a fully portable “Perl on a stick” version that included a Perl program to fix up paths based on where it was installed.

from Kirti Poddar on Flickr

Strawberry Perl was supposed to lead to Chocolate Perl, something enhanced even further for people who were familiar with Windows but not Perl. It would include GUI tools and other niceties to avoid the command line (See Vanilla and Strawberry (and Chocolate) Perl 2008 Plans).

The Strawberry brand was enough for most people. In 2010 Curtis Jewell created “Strawberry Perl Professional” as an enhanced distribution with big frameworks, such as Catalyst, and task oriented sets of modules, such as BioPerl. There are other distributions built on top of Strawberry Perl, such as DWIM Perl, that add GUI tools.

See Also

Windows Perl: A short book project

I want to write a short book about Perl on Microsoft Windows—something less than a 100 pages. Now that I’m done with Mastering Perl, I have a little time to work on it. I’d like to have this done by the end of February.

I’m not a Windows person, but that’s one of the reasons I want this book. I want to document and collate into one place the various bits of knowledge about Windows, including:

  • Working with Windows filenames
  • Interacting with external processes
  • Interacting with system databases
  • What doesn’t work on Windows (and now to get around it)

A long time ago, there was a variant of Learning Perl that covered some of these: Learning Perl on Win32 Systems. I always liked Randal’s comment about that book when people would ask him what was different: “I don’t know—I wrote the parts that were the same”. That book only got one edition, but some of the stuff deserves to live on.

I’m just getting myself organized on this. If you’d like to help me shape the outline of the book, leave a comment or send me email. I’m especially interested in what you think Perlers on Windows should know.

Some notes

I’ll collect notes and other things here, and try to respond to comments as they come in.

: briandfoy: Perl is POSIX with a Win32 backward compatibility layer to some extent

* : briandfoy: I poked Perl on windows twelve years ago thanks to a client of mine, What I learned is that Perl on Windows will always be second class citizen due to to Perl’s internals and POSIX nature (for example the emulation of file descriptors and lately the penalty of ithreads and pseudo fork vs the former native thread support)