Using Padre for the first time

Recently I have been doing some in depth research with regards to development tools of all kinds. Currently I am working my through the various IDEs available in both the open and close source worlds. This is what spurred me into giving Padre another shot. The last time I tried to install it there was a dependency problem and it was not worth solving. So that is my first step, install Padre.

Padre install perfectly in my openSUSE 12.2, Perl v5.16 development environment. I immediately started the application and loaded a script I wrote a few weeks ago. I have never used Padre, seen screenshots of it or really been interested in it, that is my perspective going into this. The first thing I did was go to the Window menu and see what helper windows are available. I started the CPAN Explorer and ran a search. It was fast and I assume it is reading the local module list file that cpan uses. Then I click on Recent and hit Refresh and the most recent CPAN modules show up, just like the metacpan recent page.

That feature alone makes it better than most of the IDEs out there for Perl development but would we expect less? It is written in Perl by Perl developers and they have a good grasp on what information developers want. Next I wrote a little code and then opened the Regex Editor to give it a shot. I like the list of quick references on the right for things like Character classes. Setting ixmsg flags are done via check boxes at the top of the window. Inputting some test data and a simple regexp I run into a problem.

The regexp I used was \d{2,3} something simple. Now when no match is found the 'Matched text' area shows a 'No match' message in red. When the regexp matches a substring of the sample data we see all of the sample text again in the matched text area but the actual match is not highlighted. I expected it to highlight the matches in this area as a visual aid to find the matches quicker. I tried substitution and the replacements were not highlighted either.

Moving on I started looking for the must have features that all good code editors have.

  • cross platform
  • full unicode and utf-8 support
  • visible line numbers
  • current line & column number
  • syntax highlighting
  • brace matching
  • auto indentation
  • view spaces and end of line characters
  • Different files as tabs
  • multiple level undo/redo
  • code folding
  • block commenting
  • new line conversion
  • Perl integration (syntax check, debugging)
  • text zoom
  • double click word selection
  • triple click line selection
  • find in files
  • regular expression search and replace (Only in the Replace option. The normal find does not support regexp)
  • multiple instances
  • generalized autocomplete
  • session state preservation (only if you choose to save it)


I found almost everything I expected in Padre and the rest via plugins. Padre::Plugin::PerlTidy added perltidy support after I restarted Padre and enabled the plugin via the Plugin Manager. For Padre::Plugin::PerlCritic I followed the same routine and it by default does nothing if you do not have a minimal .perlcriticrc file. With a perlcriticrc file in hand I tried running it again and now I get output. The problem though is how the output is displayed. First off this plugin does not honor the verbose setting from the config file. No matter what I set it to the Padre output is the same. The second problem is the lack of colorized output or other indicator of the severity level of a warning message.

Next I went to Tools, Preferences to change a few options around. When I saved the changes the File menu bar disappeared, which is no good. I started up a test Windows XP environment, installed DWIM Perl 5.14.2.1 (v7) and tried the same process again and it did not mess up. So after having to restart Padre a bunch of times after making configuration changes I started using it to update a few scripts I wrote last month. Four segmentation faults later and I am done with it. I have no interest in fiddling with it to figure out the problem, I tried it out for research and now I know what it can and cannot do.

Would I recommend Padre to other developers? No.

Padre uses the Scintilla library which is where it gets the bulk of its features from. SciTE is an editor developed by the Scintilla developers that does most of what Padre does without crashing constantly, is updated more frequently and is cross platform as well. The extra features like CPAN Explorer, refactoring, and other Perl specific goodies I already have via command line applications. I started out excited to try Padre in the hopes it could make things a little faster in the development cycle. Now I just regard it as another buggy IDE. And please do not feed me a junk line about it works on my Linux distribution, I do not care. Pretend I am a normal end user for a moment. If I install a piece of software and it crashes repeatedly I simply switch to another application. I am not compelled to try and fix it or figure out what is going on, I am not invested in it as a first time user.

15 Comments

Thanks for this story. It happened to me as well and I thought I'm just to stupid for it... now I stick to VIM ever since, even if I don't use it's to me unknown super-cow-power features...

I now think, that any editor does not help a lot... all one need to do is writing code. And it is worth to take your time and think while typing. No editor can do this for you.

Hi

Thanx for your comments. It's been a long time since I tried Padre (under Unix). The last time I tried, I had the same sorts of issues, including the vanishing menu one.

I do understand a huge amount of work has gone into Parde, and it would be fascinating to be using an editor written in Perl, especially given the range of add-ons which could be incorporated.

I simply don't understand how, after such a long development, these gross errors can happen. It's very confusing.

As alternatives, I switched back and forth between Emacs and UltraEdit for Linux (uex). UltraEdit was ported from the Windows version, and has had a few problems, which were severe enough to drive me back to Emacs.

But now, with uex V 3.3.0.2, almost everything just works, and I've set it up with Places on the left and the file being edited on the right. And I can navigate the source code tree on the left rapidly.

See http://savage.net.au/Ron/ultraedit.png

Note: The little window on the bottom-right belongs to the GIMP, not uex.

There are a couple of problems:
o) The cursor sometimes vanishes.
o) About once every fortnight it hangs.

So, I feel sad to be recommending a non-Padre editor, but it's all about reliability and frustration-prevention.

The price of UltraEdit (about $60) dollars is tiny compared to what it does for my productivity, so I can recommend it whole-heartedly.

Also, uex has remote-logins and a large range of other features.

Cheers
Ron

I am not sure I understand. You had the time to write this long blog post, but did not have time to report the problem to the developers of Padre?

"Four segmentation faults later and I am done with it."

That neatly sums up the three times I've tried Padre over the last few years. I never even got as far as deciding whether I liked it or not, it was so unstable.

I will try it again in another six months or a year, because I'd like to like it :) but I'm not optimistic any more.

Probably my words did not come through as I intended them. I don't expect anyone to file a bug report for Padre. I was just surprised, given you invested quite a lot of time in the research and in writing down all this, that you did not have time to report it to any of the Padre developers.

Instead of that you thought it is much better to publish your negative recommendation on a public web site.

Don't get me wrong, it is totally within your rights to dislike a product and want to help other users avoiding it.

It was just a bit surprising and I did not understand why.

Oh and another note. Apparently several people got segmentation faults with Padre. How can that happen?

1) None of the developers have seen those and no one reported them.
2) The segfaults were reported but the developers could not reproduce them.
3) The developers saw the segfaults, but for some reason they could not fix those.
4) None of the developers cared.

To gabor@here

Yes, I have reported bugs.

Cheers
Ron

To kimmel@here

You say 'First time users have no biases with the software...'.

That I disagree with. We all bring our experience (pre-existing biases included) to a new situation.

That is, we have expectations of the program based on what we've seen other software do.

And many, many people are very rigid in how they judge, which is why switching does not take place all that often.

The fact the people still use vim or Emacs tells us that...

Cheers
Ron

My segfaults were non-reproducible, so I didn't bother reporting them. There's only so much even a conscientious and willing user (or developer) can do with heisenbugs, but they remain off-putting nonetheless.

Out of curiosity, installed via CPAN or installed via OS package?

Writing down the steps taken and reporting them is still useful, since it can help developers see a pattern in how the segfaults occur.

Leave a comment

About Kimmel

user-pic I like writing Perl code and since most of it is open source I might as well talk about it too. @KirkKimmel on twitter