Emacs: Friend or Foe?
Now, what about bindings involving multiple keys? For example, I like to use the key sequence C-d C-d to delete a line (somewhat like its vi counterpart), and C-d g to delete text from point to the end of the buffer. The second argument to global-set-key can include multiple keys, but the problem is that C-d already has a meaning. We want to use C-d as a “prefix” key for the commands C-d C-d and C-d g, so first we have to unbind C-d. Here's what we do:
; Various keys for nuking text (global-unset-key "\C-d") (global-set-key "\C-d g" 'my-nuke-to-end) (global-set-key "\C-d\C-d" 'my-nuke-line)
We simply use global-unset-key to unbind C-d, and then bind new meanings to C-d g and C-d C-d. However, these functions are bound to the mysterious functions my-nuke-to-end, and my-nuke-line, which the astute among you will notice aren't standard Emacs functions. We have to define them.
Defining an Emacs LISP function is rather simple. Of course, Emacs functions can be quite powerful and complex, but in this case we're going to use the function to call a short sequence of other functions, which isn't so frightening. In general, if you need a key binding to call several functions in sequence, you must define a new function to wrap the sequence in.
Here is the definition of my-nuke-to-end, which should be placed above the corresponding call to global-set-key, which uses it, in the .emacs file.
(defun my-nuke-to-end () "Nuke text from here to end of buffer." (interactive "*") (kill-region (point) (point-max)))
The defun function takes as arguments the function name to define, a list of arguments (which, here, is empty), followed by the body of the function. Note that the first line of the body is a string constant, which is a short description of the function. This string is displayed when describe-key or describe-function is used to display information about my-nuke-to-end.
The second line of the body is a call to the interactive function. This is required for functions that are bound to keys. It simply tells Emacs how to execute the function interactively (that is, when called from a key sequence). The argument to interactive, “*”, indicates that the function should not be executed within a read-only buffer. Check out the documentation for interactive if you want the gritty details. (See the sidebar “Getting the Emacs LISP Manual” for information on obtaining this documentation.)
The last line of the body uses the Emacs internal function kill-region to delete a region of text. The two functions point and point-max return the current location of point, and the position of the end of the buffer, respectively. kill-region deletes the text between these two locations.
The definition for my-nuke-line is somewhat more involved, because there is no single Emacs function that this operation maps to. Here it is:
(defun my-nuke-line (arg) "Nuke a line." (interactive "*p") (beginning-of-line nil) (kill-line arg) (if (= (point) (point-max)) (progn (forward-line -1) (end-of-line nil) (kill-line arg) (beginning-of-line nil))))
First of all, we see that this function now takes an argument, which we have called arg. Many Emacs key functions take a single numeric argument, which you can specify by prefixing the key with C-u, followed by a number. (That is, unless you've rebound C-u, as we have.) This numeric argument changes the behavior of certain functions. Here, arg is passed along to kill-line, used on lines 4 and 9 of the function body.
my-nuke-line is essentially a wrapper for kill-line, but takes care of a special case for the last line in the buffer. In this case, we want to delete the newline before the last line, which causes the last line to be clipped out altogether (otherwise, Emacs deletes the line, but leaves a blank one in its place). After interactive is called (with the “*p” argument, which causes arg to be converted to a number), beginning-of-line moves point to (surprise!) the beginning of the line. kill-line is then invoked. Note that kill-line only kills text from point to the end of the line; not the entire line.
Next, we compare the cursor position (point) with the end-of-buffer position (point-max). If they are equal, then we are trying to delete the last line of the buffer, and want to kill the previous terminating newline. We move back a line (using forward-line with an argument of -1), move to the end of that line, kill the rest of the line (which consists only of the terminating newline), and move back to the beginning of the line. All of this results in the last line of the buffer being deleted.
I'm sure that there are Emacs gurus out there that can find much better ways to accomplish the same thing; please bear with me. I've been brainwashed by vi. One of Emacs' better features is that there are many ways to modify its behavior.
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
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
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