Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

What editor do you use for Perl programming?

posted by Simon on 2002.04.25 13:56   Printer-friendly
Chad writes "So I'm looking for an editor for my Perl programming. I realize that any old text editor will do, but I want something that will help me be a little more productive... At the risk of starting another Editor Holy War, the question I'd like to ask is: what editor do you use?"
He adds: "You know: color syntax highlighting, auto-indenting, code completion, error detection. I've pretty much settled on XEmacs because it offers the best set of features I have been able to find, but a major problem of XEmacs is that its syntax highlighter chokes on any but the most basic Perl constructs. [Ah, the great perl-mode/cperl-mode confusion... - S.] I've tried Komodo, which offers some nice features like running your code through Perl to find errors as you code, plus a perfect understanding of Perl syntax, a nifty regular expression toolkit, and a cool feature called code-folding, but it's still a bit buggy (copy and paste doesn't always work; code folding sometimes slurps in more lines than it should), and it sports a $300 price tag."
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • See
    • Re:VIM ! (Score:3, Informative)

      right on... []

      Two of my favorite things:
          Editing features for advanced users []
          .vimrc options to assist with perl coding []

    • I generally use vim when I work under Linux (but not so much by choice, more because it's what comes up when I type 'vi', which is my editor more or less because it's the first Unix editor I became acquainted with). When I work on Windows, I usually use TextPad, and when I write code on our HP-UX machine at work, I usually use gvim.

      I wouldn't necessarily advocate them since I didn't choose those based on careful evaluation of two dozen editors; they're just what I happen to use.

      Esli epei eto cumprenan, shris soa Sfaha.
      Aettot ibrec epesecoth, spakhea scrifeteis.

  • Does all of that stuff really make you more productve? I find that syntax highlighting and "code completion" just get in the way more times than not. Thus I use vi in all it's varied guises and I'm perfectly happy.
    • Code completion annoys me. It seems intended to be a crutch for those who don't yet know the language very well.

      Syntax highlighting on the other hand makes it very easy to spot typos in Perl. If you mis-quote something, or leave off something you shouln't, you'll know it because the next few 'paragraphs' of code will be the wrong color.
      • In Java, I find it useful for when I'm learning a new library. It's also decent for using libraries that implementLongFunctionNamesForEverything() so I can just type 'imp<TAB>' and pick the right one. In that other language, it's also useful for argument order, particularly for overloaded methods.

        M-x auto-bs-mode

      • Code completion annoys me.

        Automatic code completion would probably annoy me too, but in Vim I find Ctrl+P invaluable for completing partially typed words.

        For example if you have a variable called $inner_template_filename then merely typing $inn then pressing Ctrl+P will type this. It's a great time-saver, reduces typos, and means that using meaningful identifier names is much less painful.

        (There's actually slightly more to it: Ctrl+P repeatedly cycles through different previously-used words that ca

  • These editors come with KDE.

    They highlight Perl syntax intelligently, have plugins available for code management, and are pretty comfortable for someone who grew up with windows but moved on to Linux.

    You don't have to take the time to learn the ways of emacs or vi, which can take some time indeed if you haven't any mentor to guide you. Some may scoff, but I say the best tool is a tool you can use easily and regularly. For me kwrite/kate is just that.
  • Kate is nice, though there's a really nasty bug in the KDE 3.0 release version which slows down the editor significantly using the Perl syntax highlighting. Apparently it's fixed in KDE 3.1 though.

    So when I have to edit larger files, I use gvim (looking forward to kvim though) with the Cream [] extension, which turns vim into a single-mode editor with CUA keystrokes. It's a little buggy, but quite usable.
  • Windows:
    • Visual Perl []. Hands down the slickest interface for Perl I have ever seen. This one does it all. Of course, this requies Visual Studio .NET (in addition to the Visual Perl license). You have $1000 laying around, right?

    Both Unix and Windows:

    • PerlBuilder []. Doesn't look like they work much on the Linux version, though (I ripped it off my machine if that tells you anything). Pretty good, and has some handy CGI development stuff.
    • SlickEdit []. Very nice, but no debugger. A multi-language tool
  • I use emacs, with fundamental-mode. Syntax highlighting may be fun, but after a while I am fed up with comments in light pink over white, keywords in pale blue over white, strings in light green over white, and the like. Also, I like my indent style and indent length, not the one perl-mode or cperl-mode gives me.
  • by hossman (2110) on 2002.04.25 15:40 (#7546)
    First and formost, choice of editor should be based on individual comfort/style, not how well it's integrated with a particular language. I like emacs commands, I like most of the emacs default key-bindings, I like the overall feel of emacs -- so I use emacs. Other people can say the same thing about vim, or Komodo, or Kwrite, or TextPad or whatever you want -- that's the first step towards narrowing down your seletion, make sure you like the editor as a basic editor.

    Odds are, if an editor is good enough to pass that first test, it's ging to offer customizations, it's going to offer support for particular programming languages, then go look at those and decided if you want to use them. If you want syntax highlighting, turn it on; If you want auto indenting, turn it on; If you want code completion, turn it on. Personally, I hate code ompletion, but I love auto-tabbing and syntax highlighting. They help me see typos faster.

    Personally, I use perl-mode, and the only problems I've ever had with it not highlighting the way I think it should is when I put funky characters like '#' or '"' inside qq() or qw(). The only time it doesn't auto-indent in a way that makes sense is when it sees something it thinkgs is code in here docs. I don't mind either of these, because it shows me places where other people would probably be confused by my code at first glance as well.

    Again, any editor worth using is going to be customizable, if you don't like the default tabing depth in perl-mode, tweak it; if you don't like the colours used or comments, tweak it. But those aren't reasons NOT to use an editor, or not to use the language speciffic support in an editor.

  • I'm currently drinking the Emacs Kool-Aid. Choice of flavor: GNU.

    I used to swear by VIM. From the day I discovered emacs, I had the feeling that I was supposed to learn it, and that I would, "some day." It just seemed like the thing a UNIX person was eventually supposed to do. My switch from straight vi to vim just about killed that desire; I figured it was good enough, and I was highly productive with it.

    Then I started noticing that a lot of the programmers I respect use emacs. I started suspectin

    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • Thank you! As it is now 11:33 in my timezone, I have officially learned two things about emacs today, making this a very good day indeed. :)

        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • GNU emacs and cperl-mode. I don't use colouring, but I do use indents. (I find cperl knows more about how to indent code than does perl-mode, but both still get confused. I hope to hell perl6 makes it easier and not harder for indenters).

    I've been yearning to treat my code like a collapsable outline, hiding everything but the subroutine I'm working on and the names of other top-level subroutines. I think I remember cperl having something like that, so I guess it's time to RTFM :-)

    I've never needed f

  • Jedit (Score:3, Informative)

    by Matts (1087) on 2002.04.25 16:23 (#7552) Journal
    One editor I forgot to mention in my post below is jedit [].

    Now you need a snappy PC for it, since it's Java+Swing, but if you have that, it's probably the kick-iest ass-est editor around. It's got some absolutely lovely features in it, like if you hover over a brace, it doesn't just highlight the other brace - it shows you in the left-hand column a foldable section marker, from the start of the block to the end. And it will do this while you're in a block too. It's got some sweet plugins, like an XML plugin that shows MS-Word-like squiggly red lines when you type the XML wrong. Built in project management. Console windows. FTP plugins. Email plugins. Basically it's like emacs but usable ;-)

    All in all, I'd use jedit all the time if I had a 2Ghz PC. But I don't, so I don't use it - it's just too darn slow.
  • Everyone's already thrown emacs and vi, in their various flavors, into the mix. I find personally that I tend to use emacs the most, but....

    When writing code for CamelBones [] on my mac, I use Project Builder. Sure, it's not quite as full-featured as emacs, nor as keyboard-terse as vi, but it works pretty well, and as an integrated editor/build environment it more than meets my needs.

  • I use vim for everything I do. Except, that is, for perl, which I use XEmacs + CPerl mode. I do most of my editing in text mode on remote boxes in an SSH session. This means I edit Black background and white (grey80, actually) text. In a good clear mono type face (I like lucidatypewriter bold myself) the colorization works spectacularly for me. (Though it does blow up on I've tried the perl modes in vim, and I've had a dalliance with Kate (don't tell my wife). Vim's colorizer works very well and I could A
    • I have this in my .vimrc:

              set shiftwidth=8  " sw:  a healthy tab stop
              set textwidth=72  " tw:  wrap at 72 characters
              set autoindent  " ai:  indent to match previous line
              set cindent  " cin:  Use C-indenting
              set cinkeys=0{,0},!^F,o,O,e  " cink:  Perl-friendly reindent keys
              set cinoptions=t0,+4,(0

  • Don't forget that emacs understands the perl debugger (or rather, the perl debugger recognises emacs and reacts accordingly) so debug your perl in emacs - one window shows the debugger, the other window steps thru your source with a highglight for "the current line". Plus emacs understands perldocs, you can run a shell within emacs and so integrate your command line with your editor, it understands most source code control systems ... the point of emacs is not "just an editor" but "an environment for softwa
  • I use PFE under MSWin. []

    It's unobtrusively simple-looking, which makes it easy to forget that it's nicely reconfigurable, esp. in keybindings. Apparently free, too!

      • It breaks several of my habits in vi.

        Which ones? vim is supposed to be fairly compatible with vi (especially if the 'compatible' option is turned on).

        The only thing that comes to my mind is that you can't type 'uu' to go to the last line where you changed something (since vim has multi-level undo by default, the second 'u' won't Undo the Undo -- but one can probably turn that hebaviour off). But then, I'm not a hard-core vi user. What, specifically, breaks for you? (Honest question.)


        Esli epei eto cumprenan, shris soa Sfaha.
        Aettot ibrec epesecoth, spakhea scrifeteis.