Emacs: Friend or Foe?
If you're like me, you find Emacs somewhat intimidating. Well, if you're like me, you've been an exclusive vi user for years, and have always wanted to start using Emacs, but have had trouble doing so. Each time you try to switch over, you find yourself pressing <esc> after every third sentence, which (in Emacs) produces some random, and usually undesirable, result. Once, I was thrown into the infamous “Doctor” mode, which is a simple AI program emulating a psychiatrist. There, I spent a good ten minutes telling Emacs what I thought of it. (The response was, "Perhaps you could try to be less abusive.")
Using one of Emacs' vi-emulation modes isn't of much help, either; none of them seem to handle even basic vi commands appropriately. And if you tend to use less-well-known vi features, you're simply out of luck. (Ever try changing the window size with nnnzwww^? I didn't think so.)
As impossible as it may seem, you can find a place for Emacs in your everyday life. If you have the diskspace and memory (a far-from-negligible detail), I strongly suggest looking into Emacs; it can make your life easier, even if you think that you're perfectly content with vi.
Whether you're accustomed to vi or not, however, the default Emacs configuration on many systems is, well, less than adequate. While many users learn to live with Emacs “out of the box”, I've never been content with that approach. Instead, you can get Emacs to do just about whatever you want it to do. So, let's take a look at some customizations that I've found particularly useful.
All of the customizations discussed here involve editing the Emacs configuration file, which is ~/.emacs by default. This file is written in Emacs LISP (Elisp), which is the internal LISP engine that Emacs uses for nearly everything. For example, keystrokes map to Emacs LISP commands. You can modify the command to be executed for each key sequence, and even write your own Elisp functions to bind to keys.
If you're not a LISP programmer, never fear. Most of the LISP forms described here are quite simple and don't require a degree in artificial intelligence to comprehend.
I do assume that you have at least tried to use Emacs, and know how to get into and out of it, are familiar with the Info documentation system, and so on. If not, fire up Emacs and type Ctrl-h (C-h) followed by t, which will drop you into a tutorial. (From there, you're on your own.) The following customizations work under Emacs 19.24. By the time you read this article, there will more than likely be a newer version available, for which certain things may have changed.
Before we can customize Emacs, we need a customization file. By default this is .emacs in your home directory. (Later, we're going to move the contents of .emacs to another file, so buckle your seatbelt.)
Our first task is to rebind several keys to perform more reasonable actions. Admittedly, several of these key bindings are vi-oriented, but should make sense nonetheless. First of all, I like to page back and forth through the document with C-f and C-b, as in vi. In order to rebind these keys, we'd include these lines in our .emacs file:
; Modify meaning of C-f and C-b (global-set-key "\C-f" 'scroll-up) (global-set-key "\C-b" 'scroll-down)
As you can see, comments in Elisp begin with a semicolon and extend to the end of the line. Here, we invoke the function global-set-key twice; once for C-f and again for C-b. In LISP, expressions are parenthesized. The first item in each list is the name of the function to call, and it is followed by any arguments. The first argument to global-set-key is a string constant, representing the key sequence to bind. The second argument is the name of the Emacs LISP function to bind it to. The function name is single-quoted in order to refer to the function name itself, not the function that it points to.
One question remains: How did we know that scroll-up and scroll-down referred to the Emacs functions to scroll pagewise through the document? Other than reading the documentation, you could find this out by using the Emacs function describe-key (which you can invoke with C-h k). Calling this function and following it with a key sequence will tell you the Emacs function name that the key sequence maps to. If you knew that the Emacs keys C-v and M-v (Meta-v, where “meta” is usually the <esc> key) scrolled back and forth through the document, you could use C-h k to determine the function names for these keys. For example, the sequence C-h k C-v will display the function name bound to C-v.
Here are a few more key rebindings that I use often:
(global-set-key "\C-v" 'end-of-buffer) (global-set-key "\M-v" 'beginning-of-buffer) (global-set-key "\C-p" 'yank) (global-set-key "\C-u" 'undo) (global-set-key "\C-r" 'overwrite-mode)
The first two commands rebind C-v and M-v (which previously scrolled by pages) to move to the beginning and end of the buffer, respectively. The third causes C-p to yank the previously deleted or copied region of text, and the fourth causes C-u to execute the undo command. (I tend to use the Emacs' undo feature quite a bit, and find C-x u or C-_ too cumbersome.) The last command causes C-r to toggle overwrite mode.
There are some caveats associated with rebinding keys in this manner. For one thing, it destroys the previous definition of the key. In many cases, this is fine; as long as you didn't use the key as previously defined. However, the last of the above commands rebinds C-r, which is used to invoke a backwards incremental search; a very useful feature. Before rebinding a key you should be sure that its previous definition doesn't mean much to you.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide