Text Editor Qeustion

[Anonymous Monk]

Hi Monks

I started using gVim on Windows to write some sys admin type Perl scripts that could be from a few to about 200+ lines. I was earlier using Komodo Edit. While I really like gVim, the more I try to add stuff like neocomplete/syntastic, the slower/quirckier it becomes. Using PerlCritic throws ups wierd errors in gVim. I've spent weeks trying to fix it, but now it's at a point where I'm fighting more with the plugins than using it for writing scripts. Is there anyone here who uses something like KomodoEdit or similar? Do you think using Vim (or Emacs perhaps) actually makes you a better Perl Programmer? Can one still use an IDE and be a good Perl Programmer? Apologies if my question appears superfluous, but would be thankful if you folks could answer.

[MidLifeXis]

An editor (or any toolchain) is only as good as it allows you to perform. I often times compare a good development environment to a mechanics tool chest. There are some worn tools that look ugly, but perform a job very well for a particular mechanic. The same tool in another mechanic's hands may cause them to lose a thumb. There may be a tool created by the mechanic for a particular job. There may be a couple of tools way in the back of the lowermost drawer that are only used once in a great while, but allow the job to be done right.

Basically, if you have the flexibility (for example, team mechanics may dictate a standard toolset), become intimately familiar with your toolset. If a certain tool causes you to injure yourself, either modify it or switch tools. Learn your preferred toolset well and the functional basics of others that you are likely to encounter.

Personally, I use Emacs with org-mode, magit, perl-mode and cperl-mode (each has its strengths), a unit testing framework (called on file save), some format shackles, various other modes for other languages, ECB for some window management saneness, tramp for editing of remote files, vlf for large files (edits using a sliding window), and a bunch of home-grown tools that make my programming life easier. I have used Emacs for 20-mumble years, so it is comfortable. I use vi, sed, awk, and so on when it makes sense.

Different toolsets have different nuances that fit different styles of programming and programmers. Find one that fits and learn it well.

[GrandFather]

I use Komodo IDE which is the Komodo editor and a pretty good integrated debugger. I'd argue that I'm a pretty good Perl Programmer, but I'm biased. I know that having a good IDE and knowing how to use it can make up for a lot of programmer deficiencies!

One of the most important things about a good IDE is that I can write a few lines of code then very quickly check in the debugger that things are as I expect. That saves a huge amount of time that would otherwise be spent poring over trace output or running the code with pen and paper.

[LanX]

Someone said "Emacs is not an IDE, it's an IDE construction set."

Every emacs crack I know has a totally unique set up, it's like entering a new universe.

Komodo is an awesome commercial tool, with a single development team creating a uniform experience.

If you like it, stick with it!

But if you want the full power to customize an open source tool with millions of possible extensions to fit your personal taste ...

... then you have to pay the prize of a complicated learning curve and to fiddle with sometimes frustrating half tested modules.

[BrowserUk]

I used to use an IUO editor that had a very powerful, c-like macro language built-in. I wrote some amazing macros using it; like one called picoDraw that allowed you to drag the cursor with the arrow keys and draw perfectly formed boxes and tables using the old OEM line-draw characters. As trails crossed, the appropriate corner, tee or cross piece was left behind.

I now, and for a long time, use a relatively simple programmer's editor with nothing more than a keystroke recorder/replay macro facility; a built-in file-compare, and a customisable, call external tool facility and little else.

The problem with the all-singing, all-dancing, totally customisable editors is that: a) they are never particularly well configured from the get go -- better to "start minimal and allow the users to do there own thing" they reason; b) you are never quite satisfied with them. There is always another mode, plug-in or macro that helps in some obscure, occasional situation that can be added.

And the problems with that are: a) you're forever customising it; b) forever debugging the latest additions and the interactions between them; c) forever downloading the latest versions of those in order to stay current; d) never quite commit the multitude of different modes and key sequences to mind and muscle memory. So you never quite become fully familiar with your tool.

Whereas my simple editor since circa. 1995. It has gone through 4 or 5 major and myriad minor updates in that time; and yet almost nothing has changed. I mean nothing that impacts my nearly 20 years of muscle memory. Its got prettier. Gained a few things. But for the most part I can switch between versions and unless I go looking, not actually notice any change. (It even has the same few minor annoyances!)

When it comes to the most important tool in the programmer's kit, there is an awful lot to be said for stability.

Any manipulations the keystroke macro facility can't handle tend to be one-offs; so I use a perl one-liner to do them. If I find myself doing the same thing a second time, I make the one-liner a script and tuck it away in a dusty corner of my disk in case I need it again. The only real problem then is trying to name them to something one will recognise a few years down the road.

[flexvault]

BrowserUk,

". . . When it comes to the most important tool in the programmer's kit, there is an awful lot to be said for stability. . ."

Never thought about it like that, but I think you are correct as usual.

Regards...Ed

[flexvault]

Dear AM,

When I came to Perl, I had a number of years of programming under my belt already, and I used an editor I wrote in the 1980s to do all Perl script work. I had used SPF in IBM, and when I left IBM I programmed a similar but limited version in 'C'. This version was buggy, and needed constant tinkering if and when I used a different hardware/operating system/etc. ( Note: 'C' is not as forgiving as Perl! :-)

After about 6 months of use with Perl, I re-wrote it in Perl. This, as I look back on the events, was one of the best decisions in my business life. After that, when I had to work on a new/different system, I just copy my Perl spf-like editor and start working. Instant productivity!

I haven't looked at the code in years, and the last time I did look at it I realized I wrote a 'C'-like Perl script, that should be re-written to be Perl-like. But because Perl allows dynamic arrays, I don't have to worry about the size of the file I'm editing. I have a limit of 8,000,000 lines so I don't run out of memory, but I've never hit that limit.

So this small, stable little script is one of my best tools for programming.

I turned 70 this week, so I'm very glad I don't have to learn/re-learn new IDEs. As stated by BrowserUk ". . . When it comes to the most important tool in the programmer's kit, there is an awful lot to be said for stability. . .".

Good Luck...Ed

[LanX]

you might find this old "meta" discussion interesting :)

---> What are the criterias of a "good" Perl IDE?