Pages

Thursday, December 20, 2012

As I wrote in my first commentary on Steve Losh’s
Learn Vimscript the
Hard Way, I think it is a worthwhile book for people to read to get
more familiar with the mechanics of customising their Vim environment.

What about those who want to use it to actually learn Vimscript?

It does an acceptable job of that too.

The chapters on Vimscript itself (19-27 and 35-40) cover the syntax
and semantics of the language with examples and exercises spread
throughout to give the learner necessary hands on experience.

I want to stress here that I feel Steve didn’t intend the what of
those examples to be used literally in anyone’s vimrc files or
personal plugins (in fact, I believe that to be true of the whole book
at large) but rather the how of techniques shown. Don’t create your
own little maps in your ~/.vimrc file for commenting lines in
various filetypes and don’t write your own toy snippets system — very
good plugins exist for these purposes already. Do learn that you
can do these sorts of things so that when the time comes for you to
really write something new, you will know how to.

Steve also provides two larger exercises starting respectively at
chapters 32 and 41. The first is a new operator to grep for the
motioned text, and the second is a full blown Plugin for a new
programming language. Both serve as good models for the sort of larger
works of the practising VimLer.

I do recommend this book because it’s freely available to read online.
Another resource I would recommend for learning Vimscript is Damian
Conway’s five part developerWorks article series,
Scripting
the Vim Editor — that’s how I first got into VimL (VimL is short for
Vim Scripting Language and is another name for Vimscript). Vim’s
built-in :help usr_41 is the user guide to writing Vim scripts
and :help eval.txt is the reference manual on VimL’s expression
evaluation.

Do you have a favourite resource for learning VimL?

[update]
Oops... I forgot to add my remarks on some of the technical aspects of Steve's work:

As Steve says, always use :help nore maps until you know you need otherwise.

In the same vein, always use :normal! (instead of the oft shown :normal) to avoid user-defined keymaps on the right hand side.

The :echom command (and friends) expects the evaluations of its expressions to be of type string. Use :help string( to coerce lists and dictionaries to strings for use in these commands. E.g. :echom string(getline(1, '$'))

Vim's help system is context aware based on the format of the help tag. See :help help-context for the list of formats.

It’s badly titled, imho. His definition of the book explains why I say
that: a book for users of the Vim editor who want to learn how to
customize Vim. With that description in mind, I think the book
achieves its goal — a goal that all vimmers would aspire to master.
However with the title of the book, I fear even many proficient
vimmers would assume that the material is out of their reach or too
dense to absorb right now with their busy schedules, relegating it to
a later reading pile, at best.

For all you up and coming Vimmers looking to read something to take
you beyond all of the beginner tutorials out there, read chapters:
0-18, 28-32, 43-48, 50 & 56.

For those of you who picked the book up specifically because of its
title, that review is coming soon. :-)

Sunday, December 16, 2012

There’s probably nothing surprising there except for the a:a
syntax, which is how Vim insists on accessing the function’s arguments
(mnemonic: a: for argument).
Just as simple is calling function A() from another function, B(),
passing its arguments directly along to A():

Nothing surprising there at all. But we’ve just laid the groundwork
for the main attraction tonight. In VimL, you can call a function
using the library function call(func, arglist) where arglist
is a list. If you’re calling a function that takes multiple arguments,
collect them in an actual list like this:

It’s worth stopping briefly here to consider what call() is doing
to that arglist: It’s splatting it (extracting the arguments and
passing them as separate members to the called function). Nice.
Wouldn’t it be nice if we could splat lists ourselves? Well, be
envious of Ruby coders no more because we can splat lists in VimL!

Splat!

To splat a list into separate variables (a, b and c here):

let [a, b, c] = somelist

Read :help :let-unpack for the juicy extras.

I like the splatting approach because it gives us variable names to
play with inside our function:

You’ll notice that the splat semantics are identical between H()
and I() and only the call of D() and C() change,
respectively. This is very neat, I think.
So far we’ve been calling through to functions that call A()
directly. Happily, we can call through to one of these dynamic
functions (like E(), but any would work as well) and have it Just
Work too:

So, that’s it. Vim has variadic functions and splats. And splats are my
recommended pattern for handling deep call chains between variadic
functions.
There’s one last, cute, little thing about splats: you can collect a
certain number of explicit arguments as you require, and then have any
remaining arguments dumped into a list for you. The rest variable
here will be a list containing [4, 5, 6] from the subsequent
calls:

Saturday, December 1, 2012

What he showed he showed fairly well. His decision to "introduce compiler theory" was, he admitted, last-minute and the hesitation in its delivery bore testimony to that. The demonstration of the compiler pipeline using his intended tools (ruby and racc) was done quite well with a natural progression through the dependent concepts along the way. By the end of the talk he has a functional compiler construction tool chain going from EBNF-ish grammar through to generated (and using gcc, compiled) C code.

I was surprised that nobody in the audience asked the question I was burning to ask from half way through the live-coding session: Why not use Treetop? (or the more generic: why not use a peg parser generator or a parser generator that does more of the heavy lifting for you?)

The whole point of Tom's presentation is: use ruby+racc because it saves you from all the headaches of setting up the equivalent tool chain in C/C++. And it does, he's right. But it feels to me that Treetop does even more of that hard work for you, allowing you to more quickly get to the fun part of actually building your new language. I'm angling for simplicity here.

I could be wrong, though, so let me ask it here (as Confreaks seems to not allow comments): Why not treetop (or an equally 'simple' parser generator) for something like this? (and answers along the lines of EBNF > PEG are not really what I'm after, but if you have a concrete example of that I'd like to hear it too.)

On a completely separate note: Tom, you need to add some flying love to your Vim habits. :-)