It's been a while since I could do some proper hacking on fun code. Whenever I had spare time recently, I had to spend it on maintenance work. It's been even longer since I could hack on new features for Padre. Over five months, to be exact. In such a long time span, it's easy to forget lots of details about the code and its design. That is the case particularly for such a quickly evolving project.
After my first glance at the code today, I felt like I was starting from zero. But in the end, I managed to implement a couple of new features that I'm quite satisfied with. This gentle slope of a learning curve demonstrates one of the enormous strengths of the project: Most of the code is quite straightforward and easy to understand[1]. Newbies get up to speed quickly and adding features is a breeze. It's simply fun.
Within a few hours, I improved on Gabor's recent "Find method declaration" feature in that it can now use the "perltags"[2] file that is already used for class name and method auto-completion. This makes the determination of the file in which the selected method was declared a lot more robust. Too bad we can't look into Perl scalars with static analysis. This currently works only for class method syntax a la class->method. It's still an order of magnitude faster to use than searching files manually.
Next on my list was adding an XS document type with "calltips" support for the perl interpreter API. Now, when you open an XS file in Padre, you will, among other horrors, get shitty syntax highlighting because it's only recognized as a C source file. But at least Padre can now show you the documentation of the perlapi macro that you're hovering your cursor over. Trust me, that can be a salvation for misremembering, constantly perlapi-rereading and misreading XS neophytes like myself. We have a long way to go to make Padre a useful editor for XS and C, but I'm optimistic. It just so easy to get started that I can relearn the code base once every few months [3].
--Steffen
[1] "Easy to understand" doesn't necessarily mean that it's all great or elegant code. The code quality in the project varies greatly. Usually, the initial, hackish implementations are redesigned and refactored into good APIs as the need arises.
[2] Think "exuberant ctags", but for Perl. Generated with the Perl::Tags module. Thanks to osfameron for promptly uploading a new version.
[3] Next up, I'd like to add multiple copies of the perlapi docs. One for each release of perl. The user would then select the version of perl he's developing for and get the correct documentation automatically. Eventually including all the backported constructs from ppport.h. Help welcome.
