Monday, April 22, 2013

Sort Me A Column

Need to sort a column within your table without messing with the other columns?
Vim has your back with blockwise visual selections and a bit of gymnastics.

Sample table:
1 this 1 apple    is 1
2 this 4 durian   is 2
3 this 3 carrot   is 3
4 this 2 banana   is 4
5 this 5 eggplant is 5

Desired result:
1 this 1 apple    is 1
2 this 2 banana   is 2
3 this 3 carrot   is 3
4 this 4 durian   is 4
5 this 5 eggplant is 5

[wrong] Result of naive :sort command:
1 this 1 apple    is 1
2 this 4 durian   is 2
3 this 3 carrot   is 3
4 this 2 banana   is 4
5 this 5 eggplant is 5

[wrong] Result of :sort /^. / command (to skip leading numbers):
1 this 1 apple    is 1
4 this 2 banana   is 4
3 this 3 carrot   is 3
2 this 4 durian   is 2
5 this 5 eggplant is 5

A Solution

  1. Visually select the column of interest with ctrl-v
  2. Cut it with x
  3. Open a temporary scratch buffer with :enew
  4. Paste with p
  5. Sort with :sort
  6. If you need to, ensure your cursor is line 1, col 1 with gg0
  7. Visually select and yank everything, blockwisely with ctrl-vG$y
  8. Switch back to where you came from with ctrl-6 (ctrl-^)
  9. Jump to the start of your original cut with `[
  10. Paste with P

Sunday, April 21, 2013

Sohi Vila

Clearly, I use Blogger. That I use asciidoc to write my blog posts might be less obvious. For the most part, it works fine. There is, however, one little thing that has been annoying me all this time…

The blogger backend for asciidoc uses the html4 stylesheets which don’t seem to be compatible with pygments (my preferred syntax highlighting solution). I guess I could have tried to bash the blogger backend into using html5 or xhtml11 to get pygments, but there were too many unknowns there to make that worthwhile investigating. The other alternative was to get asciidoc’s default highlighter to love Vim.

Asciidoc’s default syntax highlighter is GNU source-highlight. For the most part, it does a reasonable job. Why it doesn’t support Vim files out of the box is beyond me. SohiVila fixes that problem.

Here’s some VimL lovingly rendered with it:

" PrintWithHighlighting()
" Original Code by Jürgen Krämer on vim-dev
" Modified by Barry Arthur, 2013-03-21
"
" Usage:
" * As a subcommand to the :g// command
" :g/something/P
"
" * As a standalone command
" :1,10 P
" :%P
" :P

function! PrintWithHighlighting() range
  for line in getline(a:firstline, a:lastline)
    let ms = match(line, @/)
    let me = matchend(line, @/)

    while ms != -1
      echohl none
      echon strpart(line, 0, ms)
      echohl Search
      echon strpart(line, ms, me - ms)
      echohl none
      let line = strpart(line, me)
      let ms = match(line, @/)
      let me = matchend(line, @/)
    endwhile
    echon line . "\n"
  endfor
endfunction

command! -range P <line1>,<line2>call PrintWithHighlighting()

Saturday, April 20, 2013

Partial Explosion

Vim has a powerful regex spell, :help /\%[] . While it might look like the emoticon of a lunging crocodile, this little piece of regex lets vimmers match words in either their full form or any partial reduction thereof. That’s a messy explanation. A showing will help:

The pattern:

/r\%[ead]

Will match: r, re, rea, and read

Unicorns, I know!

This actually gets a lot of love in Vim’s syntax highlighting file for its own language, VimL. I wish it didn’t to be honest. I actually deplore the availability of partial keyword forms like fu instead of the full form function. But that’s not why we’re here today, so let’s move on.

Not all regex engines support this awesome atom. In fact… I don’t know of any other that does.

I am in the process of creating a vim.lang file for source-highlighter. As you would expect, it has a regex based DSL for specifying syntax items. One such item is for keywords. Easy!, I thought, I’ll just grab the keywords from Vim’s syntax files and… oh, crap… It’s infested with \%[]

So… Let’s explode them.

With a quick regex, I got the Vim keywords split out onto separate lines, like this:

a
arga[dd]
ar[gs]
bar
bn[ext]
breaka[dd]

And then we can explode out the partial variations with this little regex:

:%s/^\(.\{-}\)\[\(.\{-}\)\]/\=join(map(range(len(submatch(2))+1),  'submatch(1).strpart(submatch(2), 0, v:val)'), ' ')/

Producing:

a
arga argad argadd
ar arg args
bar
bn bne bnex bnext
breaka breakad breakadd

And just in time for dinner, too.

I'd Tap That

The Ruby world and many others have a tap() method on a class way up in the hierarchy near God that lets the bug hunting developer peek inside of objects during execution to see what the gnomes are getting up to under the covers. I needed just such a tool for my latest dabblings in Vim, so I built one and thought I’d share it here:


function! Tap(thing)
  echom string(a:thing)
  return a:thing
endfunction

It’s not very intimidating, I know, but thats a little gem of a function. I used it to debug the setting of the includeexpr option in Vim, as shown here:


set includeexpr=Tap(substitute(Tap(v:fname),'\\${\\?\\(\\w\\+\\)}\\?','\\=expand(\"$\".submatch(1))','g'))

I was suspicious that the v:fname variable was not being set properly before includeexpr was being evaluated by Vim. Tap() proved that to be the case which allowed me to focus my debug efforts on the real cause, instead of continuing to waste time fretting over the search and replace patterns in the substitute and whether I’d escaped them correctly or not. I only wish the Tap() inspiration had come to me sooner than it really did. Oh well… with Tap() as a permanent fixture in my ~/.vimrc, hopefully it won’t take me as long to think of it the next time I need its services.

Tuesday, April 16, 2013

The Bodhi Distro


Waving, Not Drowning

#bodhilinux (freenode):

11:37:07           pug | anyone awak?
11:37:10           pug | awake..
12:05:42       sceptic | nah pug nobody is ever here anymore
12:06:39       sceptic | it's pretty much a dead distro
12:18:50    faithless1 | sceptic more like dead channel
12:20:18           <-- | faithless1 (~faithless1@101.010.10.10) has quit (Quit: Abandonando)

Our distro is the Bodhi, right?
Yet our channel burns not bright.
Carefully chat you by and by
And let no scpetic ill imply.

Neither is there Bodhi distro;
Nor yet a channel dead.
Snce in reality all is Void,
What you miss is in your head.

Apologies to Hui-neng.

I have recently switched to the Bodhi distro after Ubuntu 12.x made an utter mess of the i915 Intel video drivers. I tried Bodhi a few versions and many months ago. I liked it then and I was reminded why upon my return now. It is a very pretty distro and yet has the stability of the Ubuntu repositories behind it. Hopefully this time I get to sit for longer under the Bodhi tree.

Saturday, April 6, 2013

Bisectly

wtf?!

We've all been there before; all too often, in fact. There you are in the middle of a serious edit when all of a sudden some vile little gremlin spits at you from deep within Vim. "Argh!" You instantly seethe with indignant rage, vowing to righteously lance that festering pustule...! when the terrifying realisation strikes you - you don't know where this bug is coming from. "Gack." You say as you think to yourself: "It must be one of the plugins... surely? Ok... it could be in my ~/.vimrc... But no! I watered it only yesterday and there were hardly any weeds there. So, it's a plugin... But... which one? How am I supposed to find the menacing little urchin among all those other well behaving citizens in my plugin pool?" Historically the Vimmer faced with this situation has had very little option but to manually move plugins aside until the faulty one is found. This is a laborious, boring and very frustrating task. Even if you knew well enough to use binary search to speed up the process, it's still not something anyone wants to do. Thankfully now, you don't have to. Now, you can do it with Bisectly.


Bisectly is a plugin-manager agnostic fault localisation tool for finding which plugin is causing you nose-bleeds.


Bisectly uses BSFL (Binary Search Fault Localisation) to quickly whittle down the set of loaded plugins in search of the one causing you pain. It uses a cutesy command interface to identify which sessions the user considers fault-free (:Unicorns) or faulty (:Zombies). This process continues until a single plugin remains, which Bisectly considers to be the guilty party.

Plugin Manager Agnostic

Bisectly interrogates your normal Vim for its final set of &runtime paths before juggling those in the BSFL algorithm. As such, it should be completely independent of any plugin manager. I have tested it with pathogen only, but I don't foresee any issues with Vam or Vundle. Feedback appreciated on this.

Possible Futures

My original idea for the Zombies Vs Unicorns theme was actually in regard to using BSFL on locating faults within a user's ~/.vimrc file. I have a plugin that is all-but-finished for this purpose but it has been delayed until a better vimscript parser can be completed. Work on that is currently in progress.

I have dabbled with various solutions to this problem over the last year or so. Most of the other solutions were tied to pathogen or were broader, more generic endeavours (stretching beyond the realm of Vim). All of those solutions, though, utilised an automated testing framework to very rapidly locate the faulty component - in a matter of seconds. I had the idea for this incarnation of Bisectly today and rushed out the simpler manual code while it was fresh in my mind. However, I do intend to revisit this plugin to add support for an automated test framework.