Sven Guckes 1995-2003

Latest change: Fri Dec 26 07:00:00 CET 2003

PICO vs VI - a short comparison

Which editor is better - PICO or VI?

Summary: PICO's commands can be learned in five minutes and PICO itself is good for editing small texts with just a few changes. However, when a text becomes bigger then you will need commands that are more powerful - and these are within VI.

VI is highly customizable, allows filtering, has number prefix for commands, and invocation of a shell, has better jump commands, can read in the result of external commands, save parts of text, substitute literal strings and regular expressions...

What's on this page?

This text gives some examples of everyday editing, simple enough to let you see some of the strengths in VI.

The measure for strength can only be measured in keystrokes (pressing the keys 'Control', 'Shift', and 'Meta' do not count ;-).

You may know that Vi and its clones allow to abbreviate tasks byt mapping a sequence of keys to just a few keys, maybe just one. Therefore I will look at the commands as they are bound by default - without any kind of abbreviations whatsoever.

The advantage of a number infix

VI's command to delete a line is dd. You may wonder why it takes two keys to do that but you will find out later that this does make sense.

PICO does not allow a number info to commands. After all, everything you type is inserted.

Vi easily benefits from this when a command needs to be used more than once.

Example: Deleting some lines:

Task:  Delete the current and the following three lines.

                Type    meaning
           4x   ^k      delete current line

                Type    meaning
                ^^      set mark  (if at start of line)
           3x   ^n      move to (beginning of) next line
                ^k      delete the marked text (the line)

Result for pico: Four keystrokes (or more).

                Type    meaning
                4       enter the number four
                dd      delete lines

Result for VI: Three keystrokes.
Alright, the difference is just one keystroke. but the difference can get arbitrarily large for other situations. Here's one:

Task:  Delete the current paragraph which consists of N lines.

                Type    meaning
        M1 x    ^p      move back to previous line
                        (until on first line of paragraph)
                ^^      set mark  (if at start of line)
        M2 x    ^n      move to (beginning of) next line
                        (until on last line of paragraph)
                ^k      delete the marked text (the line)

Result for pico: M1+M2+2 keystrokes.

So, if the paragraph is just one line then this will be just two keystrokes.
[With Vi you'd delete that line with two keystrokes as well - "dd".]
But in the worst case you will have to move around a lot -
with arbitrarily many keystrokes.  Bad!

vi:             Type    meaning
                {       jump to empty line before current paragraph
                d       start deleting...
                }       jump to empty line after  current paragraph
Result for vi: Three keystrokes.

Vim:            Type    meaning
                dip     delete inner paragraph
Result for Vim: Three keystrokes.
Note:  no matter where the cursor is on the paragraph -
this will *always* work.  Three keystrokes is *all*.
That was pretty long. Let's look at some shorter examples:

Reading in the output of a command

PICO can read in files - but it cannot read in the output of a command.

Example: With Vi you can read in the current date and time with this command;


Jumping around

VI allows to set "marks" on lines, actually, on "positions" within the buffer. Example: The command "ma" marks the current position with the mark 'a'. Now you can move around as much as you like, and the command "'a" takes you back to that line.

PICO does not remember any place you had once been to, you must remember all places and move to them yourself.

Fast deletions

The VI command :g/pico/d deletes all lines that contain the word "pico" in it.

Just looking for all thos lines using PICO could take quite some time...

Substitutions aka Search&Replace

The VI command :%s/pico/vi/g substitutes all occurrences of "pico" with "vi" throughout the current file. That's all.

You do not want to do this with PICO. ;-)

More commands

Much of the benefit that VI has over PICO is the bigger command set, of course. This is possible as VI has "modes" which allow to bind the letter keys to commands, too.

Combining commands

VI allows to *combine* commands which makes it superfluous to bind many possible commands to keys.

        d0      delete from current character (excl) to start of line
        d$      delete from current character (incl) to end-of current line
The command "d$" is pretty useful so it was bound to 'D' by default.

PICO users can use this workaround: Insert a RETURN character at the position where you want to delete the rest of the line, thus making the rest of the line a line of its own; now you can delete that line with CTRL-K.

The alternative, of course, is to type CTRL-H or DELETE as many times as need be... (sorry, folks!)

Jump and insert in one step

The following two jump commands are used quite often:
        ^       jump to first non-whitespace character on current line
        $       jump to last                 character on current line
You may argue that you do not like VI because you have to change from command mode to insert mode so often. Well, you may not know that some of the available commands combine a jump and the mode change:

        A       append to *end* of current line
        I       start insert at first non-whitespace character
A deletion also makes the cursor jump, and some of these commands also change into insert mode:
        C       "change"     (delete) to end-of-line     and insert
        S       "substitute" (delete) whole current line and insert

Anywhere along that line...

Several VI commands have the benefit that you can use them from any postition *within* a text object (usually a line):

        J       join the current line with the next
Vi usually turns the end-of-line character into a space when joining lines. Should the current line appear to have a dot at the end then Vi will add *two* spaces; this is for readbility of normal texts.

To join two lines within PICO you'd have to jump to the start or end of a line first before you can delete the end-of-line character.


VI allows to define abbreviations, ie words which automatically are converted to other words.


        :ab fro for
Now, as soon as you have finished typing the word "fro" it will be converted to "for", thus correcting a (possible) spelling error.

This can also be used to input long words with a short word. Example:

        :ab pinev Pine-4.10
This gives you a fast way to insert the name of the current Pine together with its version number.

PICO does not have abbreviations, of course.

Regular WHAT?

"Regular *Expressions*". The idea is that you can use some characters as "meta" characters, ie they make up for describing sets of characters or arbitrary many characters of some set. This description then stands for a big set of strings - far more than you can ever type up your lifetime.

One example of using these is to search for two strings (on the same line) that are arbitrarily afar [*] from another:

        foo   a lot of text in between so you cannot see the bar
VI allows to find *all* of these pairs easily with the command
The dot character ('.') is such a meta character here - it stands for "any character". The star character ('*') means "any amout of the previous". Putting these together it means "anything for any number".

WARNING: Yes, meta characters can get into your way when you don't want them to be meta characters. Example: Searching for just "." (just the dot) will find the next character as you are hereby searching for "any character". This is a problem, of course, when you do not know about the dot being a meta character, of course. This certainly increases to the learning curve - but it also has a nice benefit later.

Unfortunately, there is no switch to turn the meaning of meta characters off. Then again, a switch for this is not really a good solution. The better solution is to allow switching off of each meta character individually. This is possible by "escaping" the meta characters' special meaning by preceding them with a backslash:

This will find the number "123.456" - ie with a dot between "123" and "456".

If you still find this example to be awkward thing then consider this example:


Formatting of text with quote levels

The Situation: Email and Usenet messages usually have cited text. Text is cited/quoted by prepending the lines with some characters, usually with "> ", that is greater-than + space. (Some programs use the bracket or a percent sign.)

The Problem: Can pico reformat this text - but preserve the quote levels, too?


        > ) > % pico cannot reformat text
        > ) > % that has been quoted
        > ) > Yes, it can - you just
        > ) > have to edit very quickly
        > ) this is about *automation*
        > just use ^J to reformat
        > text within pico
        NOT with quoted text!

As you can see, the text is broken across lines within every quotation. And they almost all use their own "quote string" to indent the text.

Now, within the editor vim (vi improved) I'd use "gqap" (usually mapped to CTRL-J) on that paragraph to get this:

        > ) > % pico cannot reformat text that has been quoted
        > ) > Yes, it can - you just have to edit very quickly
        > ) this is about *automation*
        > just use ^J to reformat text within pico
        NOT with quoted text!

Now, that was easy! But what about pico? Will it ever be able to do this, too?


From: (jason carr)
Newsgroups: comp.editors
Subject: Re: pico black magic - nethack mode
Message-ID: <>
Date: Fri, 04 Feb 2000 16:04:16 GMT

I taught myself vi by making it the editor in pine.
Kind of a sink-or-swim situation, or total immersion.

More reasons?

Do you want to see more reasons? Then send an email to me, Sven Guckes

[*] "Avoid alliteration - always."  ;-)
Sven Guckes