kentcowgill.org/blog

So, being able to use autocomplete in vim saved me a load of typing last night, though I suppose it still wore out my pinky hitting 'tab'.

Do you prefer spaces to indent your code?

Have no reason to ever insert a tab into your source?

Enter vim's autocomplete a la bash style tab completion.

While you're editing, if you want to enter a symbol that already exists in the file, type the first few characters and hit tab. If there's only one match, it gets autocompleted. If there are more, vim (at least version 7, maybe earlier versions) will display a drop-down with all potential autocomplete words. Use the tab or arrow keys to highlight your desired match, then keep typing.

You might also want to change the color(s) of the drop down menu. This is handled with the following highlight group:

You might also not want to use the tab key, because you're too busy indenting your code with tabs. If this is the case, please stop doing that.

So I'm working on a new presentation for my local Perl Mongers group, and (indirectly) thanks to Ricardo Signes, I've got a cool way to get properly syntax colored code into my slides.

Ricardo has been working on an easy way to get syntax colored code into Keynote presentations. I wondered why he was bothering to convert the syntax colored code to RTF - then I realized why - I think because TextEdit.app on Mac OSX is a cocoa application, the font coloring is preserved through copying and pasting the code into Keynote, another cocoa application.

A little later on, I was creating some other presentation, and was copying some code out of my blog and happened to notice that the code I copied and pasted from Safari, my web browser, also retained its coloring information.

Problem solved, right? Anything I want to put into a Keynote slide, I should blog about first. Right?

Wrong.

That's too much blogging.

Instead, I wrote a teeny tiny little CGI to post up the syntax colored source of anything sitting around on my server, using the same Text::VimColor module on the backend.

This is that CGI:

... and then a little HTML to display it in the right font, font size, and using my standard code stylesheet - which is left as an exercise for the reader.

Hooray!

Shortly after complaining about how long my main page was taking to load, I started thinking up ways to make it go faster. As far as I could see, one option would be to try to parse the perl with perl - but just borrow all the ideas and regexes from the perl.vim vim syntax file. Easy enough - just figure out what the metacharacters in vim map to in perl, etc etc and so forth.

About a third of the way through my translation, I realized it was going to be harder than I was expecting/hoping, because there are some conventions in vim's syntax files that makes that sort of thing somewhat easy.

Plus, I wasn't even sure how good the translations were, or whether or not they'd even do anything useful:

Yuck.

I toyed with the idea of doing something with PPI, but quickly dismissed that.

I then thought I might've remembered reading something about creating some kind of "vim server" with Text::VimColor - so a quick read of that yielded nothing. But I noticed the link in SEE ALSO to Apache::VimColor, which thank goodness mentions Cache::Cache (and sibling Cache::FileCache).

What was I thinking?

So the solution was exceedingly simple:

And just like that, the page is back to being under 2 tenths of a second to create. Even with (as of this post) more than 10 hunks of syntax colored code.

Yay!

So I'm really disappointed.

That syntax coloring I'm doing for the various bits of code?

Slow.

Like, really really slow.

I know I've posted about it before, but since then, I've got 8 separate syntax colored boxes on my primary page. This takes anywhere from 1.8 to 2.4 seconds to generate.

This is not an acceptable solution.

The alternative is that at this point, I will have to come up with at least 5 posts in a row that don't have any syntax colored blocks at all before the page generation times comes down to a more acceptable level. Until then, I apologize for the poor viewing speed.

I'm going through a lot of legacy code lately, and got tired of manually opening up the first legacy file I documented (to make sure I was following the same standard I had implemented - it's not quite in my long term memory just yet), scrolling through the tedious documentation, copying (or retyping(!)) the text into the file I was working on, etc.

So, I decided to write a quick little mapping for that menial task.

First step is to create a template for the POD I want to insert:

And then this helpful mapping in my ~/.vimrc

Mnemonic: Add Pod.

... which is at least smart enough to set a mark at your current position, move to the end of the file, insert the contents of ~/podtemplate, and return to your saved position. Caveats: It's NOT smart enough to know if you've already set an 'a' mark, and it's NOT smart enough to NOT insert the template if there's already POD in the file.

So I've decided to spread my testing goodness throughout the world.

It started with a vim plugin to quickly go through some perl source and create stub test files for a given source code file.

Then I got the bright idea to create a perl module to do the same thing. Partially helped by a suggestion from Jon Rockway after a quick lightning talk about my plugin.

Available for your enjoyment is the original vim plugin as well as the perl module it evolved into, the current version of which is located in my CPAN directory

Hopefully these are of some use or helpfulness to someone. Possibly even you. :)

So I don't have much other excuse for this than to test out a few more capabilities of Text::Textile, my RSS feed, and I guess my vim wrapper for posting entries to my blog.

Spike and I were walking in the park last night, as we normally do, and again we saw a rabbit. They weren't twitterpated . In fact, there was just one. But I noticed he was fairly bold, and didn't seem to run away as easily.

In fact, the rabbit didn't seem to want to move at all. So it was fortuitous that I happened to have my cameraphone with me. Granted, I take it with me on every walk, just in case. But I thought it would be a good time to test how the "zoom" feature on my cameraphone actually worked. Also, it seemed in my viewfinder that I could hardly tell that the brown lump in the middle of the frame was supposed to be a rabbit.

Short story, it doesn't.

It more or less just "crops" an image. Same resolution, just smaller dimensions.

I was pretty disappointed.

The good news is that I can add images to blog posts fairly easily, and the formatting allowed by Text::Textile seems to be close enough to what it purports it ought to do. Also, the images show through just fine in my newsreader of choice, so anyone reading this via the RSS feed ought to see the fluffy bunnies just fine.

Also, turns out my vim blog post wrapper doesn't mangle intended Textile formatting, at least for images. Woo!

Wrote a quick little perl wrapper around vim to automate posting entries to my blog.

Really threw it together pretty quickly, but wanted to save myself the trouble of opening a web browser, typing in the site name, scrolling down, clicking on "login", logging in, etc. Just a whole lot of work. Quite honestly, no one should have to put up with that.

Maybe I should see about writing a plugin for vim, since the perl wrapper is a little hackish.

Turns out I was able to get Text::VimColor to work after all - seems I wasn't quite reading the documentation properly. See, vim needed a little help to figure out what's what - in this case, what kind of terminal it's attached to (which it isn't in this case, which is running as a CGI under apache).

According to the documentation for vim:

So all I really needed to do was give it a hint so it wouldn't complain about not being attached to a terminal. Therefore, the solution is:

Unfortunately, it's slow.

It's a known issue - this is why Apache::VimColor uses caching to speed up the HTML generation. In fact, with five code snippets on the main page (just prior to this current time of writing) case the page generation speed to go from about 0.07 seconds to nearly 1.1 seconds. That's quite an order of magnitude increase. And that's not counting adding these two snippets in a single post⁵, nor the posts in the future that will undoubtedly have more code and other syntax colored snippets.

⁵ Adds another 0.4 seconds for a total run time of nearly 1.5 seconds.

I guess I shouldn't be surprised.

I was hoping to post up bits and pieces of my .vimrc file - after all, Text::VimColor displays .vimrc syntax just fine. Naturally.

Unfortunately, Kate doesn't appear to support .vimrc files.

At least not yet.

Until I write Syntax::Highlight::Engine::Kate::Vim, I'll have to make due with using the 'LPC' syntax file, which at least colors comments differently from non-comments , and somewhat reliably.

Here's a snippet from my .vimrc for some new (to me) features that I've been playing with lately:

Enjoy!

(Note, due to difficulties and annoyances beyond my control, I've manually edited the above snippet using Text::Textile formatting.) Figured it out.

Always looking for inspiration, I happened upon Jonathan Rockway's blog and noticed that he makes use of syntax highlighting in his Angerwhale blog. After a few aborted attempts to use Text::VimColor, I broke down and decided to try out Syntax::Highlight::Engine::Kate.

I'm pretty pleased, after I finally figured out enough of how it formats bits of code and how to translate that to my vim colorscheme of choice.

All it takes is the following modifications to your text:

And if Kate recognizes your 'Language', it'll format your text.

N.B. -- I can't quite figure out how to show a closing 'pre' tag inside a 'pre' block. Hope that doesn't offend you.