180 lines
6.7 KiB
HTML
180 lines
6.7 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<TITLE>VIM Editor Issue 14</TITLE>
|
|
</HEAD>
|
|
<BODY bgcolor="#FFFFFF">
|
|
|
|
<H4>
|
|
"Linux Gazette...<I>making Linux just a little more lovable!</I>"
|
|
<IMG ALIGN=MIDDLE SRC="../gx/heart.gif"> </H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H2>Pick an Editor, Any Editor</H2>
|
|
<H4>By Jens Wessling,
|
|
<a href="mailto:"jwesslin@erim.org>jwesslin@erim.org</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
<IMG align=left SRC="./gx/wessling/V.gif"><H2>im <FONT SIZE=3>(VI iMproved)</FONT></H2>
|
|
<HR>
|
|
|
|
One day I realized that I seem to spend an
|
|
inordinate amount of time in front of a computer screen
|
|
and more precisely with a text editor in front of me.
|
|
This should hardly have been a surprise to me considering
|
|
I work with computers for eight to ten hours a day and then
|
|
I go home and spend several more. I guess that this obvious
|
|
fact finally struck home with me. I would guess I spend
|
|
about 20-30 hours a week in a text editor alone. With some
|
|
quick calculations I realized that this adds up to over 1000
|
|
hours a year. That is over 40 solid days of my life every
|
|
year in an editor. (That is a conservative estimate.) This
|
|
realization spurred me to try to optimize the time I spend
|
|
in my editor.
|
|
<p>
|
|
The first step I took was to try and find the <i>best</i>
|
|
editor around. I started asking around to see who used
|
|
what and to try to find out what the important qualities
|
|
of an editor were. <b>Don't</b> make this mistake.
|
|
Editors are one of the most religious beliefs a programmer
|
|
holds. Every programmer is convinced that there's is the
|
|
best. My office-mate uses PICO, some of my co-workers use
|
|
EMACS, VI, SlickEdit, or any one of an unending list. Every
|
|
person I talked to insured me that their selection was by
|
|
far the best. When I inquired about the differences, they
|
|
were primarily insignificant. That was when I learned the
|
|
horrible truth. Most editors are essentially equivalent.
|
|
No matter how hard people insist, most editors have more
|
|
features than any user will ever use. (Except PICO). In the
|
|
Linux community, these selections basically fall in to one
|
|
of two categories. VI clones, or Emacs. My recommendation
|
|
is that everyone learn one of these well. It doesn't really
|
|
matter which one, just pick one, stick with it and use it.
|
|
(Religiously if you must.)
|
|
<p>
|
|
I have gone to great lengths to learn VIM, a VI clone. And
|
|
certainly if not THE best, one of the top contenders. Many
|
|
features are shared among VI clones, basically the VI subset.
|
|
The additional features are basically individual to each
|
|
clone. VIM comes with most, if not all, Linux distributions.
|
|
The home page for VIM is
|
|
<A HREF ="http://www.math.fu-berlin.de/~guckes/vim/">
|
|
http://www.math.fu-berlin.de/~guckes/vim/</A>. VIM is in
|
|
active development and is getting better by the day. Syntax
|
|
highlighting should be out, if not by the time you read this,
|
|
then soon thereafter.
|
|
<p>
|
|
I will assume that most people know the basics of VI and want
|
|
to change it from a simple tool to a powerful one. I will share
|
|
some of the handy tips and tricks I use.
|
|
|
|
<P>
|
|
<U><B>Programming, Tabs, and Tags.</B></U><BR>
|
|
ctags is a marvelous utility for C and C++ Programmers. ctags
|
|
comes with the VIM distribution. What this utility does is
|
|
create a list of all the subroutine names in the files you
|
|
specify and allow you to jump to the given subroutine while
|
|
in you editor with just one keypress. The way you run ctags
|
|
is simple.
|
|
<PRE><H4>
|
|
ctags *.c
|
|
or
|
|
ctags *.cpp
|
|
</H4></PRE>
|
|
Then, crank up your editor and move to wherever it is you
|
|
call any subroutine from and press [CTRL]-]. This will
|
|
take you immediately to wherever the routine is, even if
|
|
it is in a different file.
|
|
<p>
|
|
<U><B>File Switching</B></U><BR>
|
|
I frequently work with several files concurrently and I
|
|
need to switch between these files continually. The
|
|
command to switch to another file in VIM is ":e <i>fn</i>".
|
|
The shortcut to switch to the last file edited is ":e #".
|
|
This is fine for normal use, but I switch files often, and
|
|
4 keystrokes seems like a bit much. This is where VIM's
|
|
key mapping comes in. VIM like most editors has an <i>rc</i>
|
|
file. It is called .vimrc, what a shock. 8)
|
|
In this file I have the following command.
|
|
<PRE><H4>
|
|
" Save and switch to other buffer.
|
|
map N :w [CTRL]-M
|
|
</H4></PRE>
|
|
This command lets me switch buffers with a single keypress.
|
|
The other nice feature in VIM for switching between files
|
|
is tab completion for file names. The way tab completion
|
|
works is to take whatever letters you have typed in so
|
|
far on for the file name and find all of the files that
|
|
could possibly match. Hitting tab will scroll through
|
|
the list of files until you find the one you want. If no
|
|
beginning letters are specified for the file name, it will
|
|
scroll through them all.
|
|
<BR>
|
|
<BR>
|
|
|
|
|
|
<U><B>Mapping</B></U><BR>
|
|
I do a LOT of coding and I find that I often need to comment
|
|
out blocks of lines. I have developed 2 macros for handling
|
|
this with a minimum of effort.
|
|
<pre><H4>
|
|
map C 0i/*[CTRL-ESC]A*/[CTRL-ESC]j
|
|
map T 0xx$xxj
|
|
</H4></pre>
|
|
If you examine the first line, you will see that it does the
|
|
following.<br>
|
|
<UL>
|
|
<LI>Moves to the beginning of the line
|
|
<LI>Enters Insert Mode
|
|
<LI>Places "\*" there
|
|
<LI>Escapes to command mode
|
|
<LI>Adds "*/" to the end of the line
|
|
<LI>Escapes to command mode
|
|
<LI>Moves down One line
|
|
</UL>
|
|
The second line does the following.
|
|
<UL>
|
|
<LI>Moves to the beginning of the line
|
|
<LI>Removes 2 characters
|
|
<LI>Moves to the end of the line
|
|
<LI>Removes 2 characters
|
|
<LI>Moves down One line
|
|
</UL>
|
|
I can type "12C" in command mode and it will comment out the
|
|
next dozen lines. and "12T" will uncomment a dozen lines that
|
|
were commented by "C".
|
|
<BR><BR>
|
|
Keep in mind that when you remap keys, they lose there original
|
|
values. In this case, "C" was an odd Delete until end of line
|
|
and next several lines into a given buffer, and "T" was a command
|
|
I can't really figure out from the documentation. I don't really
|
|
miss these two but be careful that you don't map "i" or "x" or
|
|
anything else you might need later.
|
|
|
|
<BR><BR>
|
|
Have fun with this. I hope to have more later.
|
|
<BR>
|
|
jEnS Wessling
|
|
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H5>Copyright © 1997, Jens Wessling <BR>
|
|
Published in Issue 14 of the Linux Gazette</H5></center>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<A HREF="./index.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
|
|
ALT="[ TABLE OF CONTENTS ]"></A>
|
|
<A HREF="../index.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
|
|
ALT="[ FRONT PAGE ]"></A>
|
|
<A HREF="./bashtip.html"><IMG SRC="../gx/back2.gif"
|
|
ALT=" Back "></A>
|
|
<A HREF="./philosophy.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<P> <hr> <P>
|
|
</BODY>
|
|
</HTML>
|