At Last, An X-Based vi
The vi editor and kin are used (if maybe not always loved) by many who value a small, nimble, no-frills programmer's editor. The keystrokes are somewhat cryptic, but mostly just terse. With a small but sufficient command set, a rudimentary set of modes, and no scripting language to speak of, vi is extensible only by modifying the source code. But it starts up in the blink of an eye. Its keyboard response speed is just short of dazzling. Sophisticated global commands are available. The learning curve is steep at the beginning, but once the muscles have learned the commands and the brain has forgotten them, vi is both fast and effortless.
Unfortunately most vi clones have little in the way of X Windows support. When running in an xterm, some will resize nicely, and some will let you click the mouse to position the cursor. But that's about it for mouse support. No scrollbars. X selection at your own peril. Not much other use for the mouse at all.
Enter vile-5.6, compiled for X11 as xvile.
While not perfect, the basis is solid, and this editor delivers:
A vertical scrollbar
Good integration of primary X selection
Mouse-based cut and paste
Mouse selection of regions for other commands
Mouse commands to open, resize and close subwindows (panes)
vi also allows commands prefaced by a colon—the so-called “colon commands”. In xvile colon commands I found a few jarring things; the release notes and help files warn about these.
While I'm no vi zealot, I've used vi off and on for seven years, so I'm pretty familiar with the command set. With xvile I found few surprises in the standard vi commands. Mostly, it just did what it should. Paul Fox (not the Paul D. Fox of Crisp fame), Tom Dickey, Kevin Buettner, and a host of others must have put in many long evenings on this project. MicroEMACS was the starting point, but this doesn't look much like Emacs. No mere Emacs vi-mode, this is a vi editor down to its code. Weighing in at about 280K stripped, it is larger than conventional vi, but small enough to be nearly as fast.
After downloading the source from a sunsite.unc.edu mirror site, I unpacked it and followed the instructions in README.CFG. Configuration and build were uneventful, and xvile ran the first time I tried it.
When I typed:
a new window popped up. At a guess, I typed:
and the main help screen appeared.
The help screens are ordinary read-only buffers, so you can use standard search and paging commands to look through them. This is an improvement over the help I've seen with other vi clones. There is, however, no introductory information, and no hypertext capability. This won't bother you if you already use vi. If you don't and would like to try this editor, a good book might help (see Resources, page 13).
There are extensions. Among these are commands to manipulate panes, rebind keys, justify text, and so on. There is a sophisticated macro capability, which perhaps I'll use some day, but the basic operation of the editor is fast partly because it does not at all depend on macros.
As with Emacs, functions are not inextricably bound to keys. Some Emacs commands have found their way into extensions to the colon command mode. For instance:
:bind-key undo-changes-backward u :bind-key format-til M-w
can provide my preferred undo binding, and adds ragged-right text justification on ALT-w. These commands (without colons) also work in the .vilerc file, as do the other colon commands, so if you have some standard setup commands, you don't have to type them every time.
If you are thinking “bind-key looks like Emacs” you are partly right. “vile” stands for “vi Like Emacs.” As the README file says, the joke is old, but somehow the name has stuck.
I wasn't delighted with a few things. Chief among these were the weaknesses in the colon commands. For example, I'm used to typing:
to write the current line to a file. xvile insists on the longer equivalent form:
which my fingers forget to type.
Many of the colon commands originate with the ancient ed, via ex, which gives you all its formidable power for the things it does very well, such as global substitutions using regular expressions. For example, to duplicate the entire contents of lines 50 to 100 in a file, with at-signs (@) for delimiters, you might type:
and a line that looked like:
would now look like:
The most common ex colon commands are there, and do just about what you'd expect, though adding some dialogue might help the novice user. An experienced vi user just starting to use xvile should keep an eye on this dialog at first, as sometimes it asks questions that won't be anticipated, or might indicate when a colon command is not having its intended effect. Once you learn the quirks, you can ignore the dialogue. But many less common ex colon commands are missing, or have incompatible implementations. I use these commands a lot, and it took a while for me to get used to the differences.
Keystrokes can be rebound, but mouse-clicks cannot. I'd sure like to bind some things like CTL-ALT-BUTTON3-DOWN to useful actions.
The copying policy is clouded. vile is derived from MicroEMACS, which is under a license that limits commercial use. The extensions are under GPL. Paul Fox informs me he's tried without success to contact the MicroEMACS authors to clarify this situation. The README suggests you buy the original authors a beer if you ever meet them.
Some xvile differences are big improvements over standard vi. For instance, if you use the simplest form of the yank command to yank ten lines of text, thus:
you may then change to an alternate file:
and paste that same text with just a p. This differs from standard vi, where the text goes away on a file change.
Another annoyance of standard vi is gone. You don't have to write your buffer to a file whenever you change windows. Don't abuse this unless you really trust your local electric power company, and your kids don't ever kick the power switch, or unless you don't mind enabling automatic save to disk. But it is a nice touch, when all you want is a quick look at another file or two or three or ten.
Unlike some vi clones, when you write a file you don't lose your place in the alternate file. In fact, xvile keeps your place in as many files as you have open.
The vertical scrollbar is handy, both for moving through the file and for telling where you are. In addition, mouse clicks on the scrollbar let you split or unsplit the window, and resize the panes.
The keypad HOME, END, PAGE UP and PAGE DOWN keys all do what you'd hope they do. So do the arrow keys. This again is different from some the vi clones.
An example xvile window is shown in Figure 1. The shaded text in the lower window is a mouse selection, to which any of those cursor-movement “operator” commands can be applied using ^s (which I've rebound to g). So in traditional vi, to delete a word starting at the cursor, you would type:
where d is the delete operator and w is the one-word cursor movement command. In xvile, you could also select a word (or three, or a few lines or whatever), using the mouse, then type:
Alternately, you can left-click at each end of the deletion with the d command intervening, thus: and so on with all the other operator commands, such as c (change), j (join), and so on. A complete list of these is elicited in xvile with the command:
An X selection can also be pasted by moving the mouse cursor where you want to paste, clicking the left button to set the cursor there, and then clicking the middle button to paste at the cursor. Rectangular selections are accomplished by holding down the Control key while doing the selection. Unfortunately, they are bound on the right by the shortest line included in the selection.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
6 hours 28 min ago
- BASH script to log IPs on public web server
10 hours 55 min ago
14 hours 31 min ago
- Reply to comment | Linux Journal
15 hours 4 min ago
- All the articles you talked
17 hours 27 min ago
- All the articles you talked
17 hours 30 min ago
- All the articles you talked
17 hours 32 min ago
21 hours 56 min ago
- Keeping track of IP address
23 hours 47 min ago
- Roll your own dynamic dns
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?