The disadvantages to using Pico are (1) it doesn't include any features to make it easier to edit program files, (2) it does automatic word-wrap, which can mess up single line comments without your noticing it, and (3) it responds slowly to cursor movement keys.
learn vi" at the shell prompt and follow the instructions.
There is a configuration option for pine that will let you use
vi either as the default editor for composing messages or as an
alternative editor that is invoked when you type "^_" in
the Message Text part of the screen.
A Unix text file is a stream of bytes, with each byte containing the
ASCII code for one character.  The end of each line of text is the
ASCII linefeed character <lf>, which has the numeric
value of decimal ten (written in C++ as the character constant
'\n' or as the hexadecimal constant 0x0A).
Strictly speaking <lf> is a control code that causes
the cursor to move down one line on the screen.  There is another ASCII
control code, carriage return <cr> (written
13, '\r', or 0x0D in C++) that
moves the cursor to the left side of the screen.  When you look at a
text file on the screen, the operating system knows enough to output a
carriage return every time is comes to a linefeed in order to make each
line start at the left margin.  DOS uses a different convention for
storing text files.  When you press <Enter>, a DOS editor
puts both <cr> and <lf> into the
file.  (Macintosh, by the way uses the only other possible combination:
it puts just the <cr> into the file when you press
<Enter>.)
DOS editors normally mark the end of a text file with ^Z
(hexadecimal 0x1A), but Unix programs such as the compiler normally
ignore ^Z and <cr> characters when they
encounter them.  The only thing is, Unix editors try to display the
carriage returns, and they show up as ^M characters on the
screen.  You can either delete them manually or ignore them if you
encounter this problem.  (In vi you can remove all
<cr>s from a file by typing
":%s/^V^M//g" where ^V and ^M
are control characters.)