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.)